kernel error mv files using ssh


deusxanime

Recommended Posts

I recently started using unRAID a couple weeks back and just a couple days ago started using binhex's rtorrentvpn docker. I have a RAID1 btrfs cache pool made up of a couple Samsung 850 EVO SSDs and the containers are on there along with the rtorrent download location. The downloads location/share is set to cache only and videos share is set to cache No.

 

I have linux CLI experience and feel fairly comfortable using it, so after some downloads completed I figured the fastest way to move from my downloads to my videos folder was to ssh direct to unraid and do the mv's at the command line. I know you shouldn't move files from disk mounts to user mount and vice versa, so first I just tried just keeping everything within the user area by doing:

 

root@yggdrasil:/mnt/user/downloads/rtorrent/completed/sp# mv * /mnt/user/videos/_staging/_anime/

 

And it came back instantaneously. Given that, I knew it didn't actually move the files to a new disk but just changed the pointers. Sure enough I went to my /mount/cache location and it had a videos/_staging/_anime/ directories now even though it is supposed to be set to use cache "No" for the videos share. So apparently that setting is not enforced if done directly via SSH/CLI, even if done within context of the /mnt/user mount?

 

So, next attempt was to just move files directly from cache mount to disk mount:

 

root@yggdrasil:/mnt/cache/downloads/rtorrent/completed/gen# mv * /mnt/disk7/videos/_staging/

 

After a bit I started getting these errors popping up at the CLI during the mv operation:

 

Message from syslogd@yggdrasil at Sep 25 14:06:57 ...
 kernel:page:ffffea0022468000 count:0 mapcount:0 mapping:          (null) index:0x1

Message from syslogd@yggdrasil at Sep 25 14:06:57 ...
 kernel:flags: 0x600000000000014(referenced|dirty)

Message from syslogd@yggdrasil at Sep 25 14:06:57 ...
 kernel:page:ffffea0023280000 count:0 mapcount:0 mapping:          (null) index:0x1

Message from syslogd@yggdrasil at Sep 25 14:06:57 ...
 kernel:flags: 0x600000000000014(referenced|dirty)

 

That is just a snippet, actually got quite a lot of those errors above, though it did complete eventually. Here's an example of what was showing up in /var/log/syslog also:

 

Sep 25 14:12:51 yggdrasil kernel: BUG: Bad page state in process mv  pfn:908c14
Sep 25 14:12:51 yggdrasil kernel: page:ffffea0024230500 count:0 mapcount:0 mapping:          (null) index:0x1
Sep 25 14:12:51 yggdrasil kernel: flags: 0x600000000000014(referenced|dirty)
Sep 25 14:12:51 yggdrasil kernel: page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
Sep 25 14:12:51 yggdrasil kernel: bad because of flags: 0x14(referenced|dirty)
Sep 25 14:12:51 yggdrasil kernel: Modules linked in: xt_nat veth xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod nct6775 hwmon_vid bonding e1000e ptp pps_core ast fbcon bitblit fbcon_rotate fbcon_ccw ttm fbcon_ud fbcon_cw softcursor font i2c_algo_bit drm_kms_helper cfbfillrect cfbimgblt cfbcopyarea drm x86_pkg_temp_thermal coretemp agpgart kvm_intel i2c_i801 syscopyarea mpt3sas isci sysfillrect i2c_smbus sysimgblt fb_sys_fops kvm libsas fb ahci raid_class i2c_core libahci fbdev scsi_transport_sas wmi ipmi_si [last unloaded: md_mod]
Sep 25 14:12:51 yggdrasil kernel: CPU: 18 PID: 8203 Comm: mv Tainted: G    B   W       4.9.30-unRAID #1
Sep 25 14:12:51 yggdrasil kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./EP2C602, BIOS P1.80 12/09/2013
Sep 25 14:12:51 yggdrasil kernel: ffffc90025d4f960 ffffffff813a4a1b ffffea0024230500 0000000000000000
Sep 25 14:12:51 yggdrasil kernel: ffffc90025d4f988 ffffffff810c8b8d 0000000000000014 ffff88107fff9b80
Sep 25 14:12:51 yggdrasil kernel: ffff88085fc9b4e8 ffffc90025d4f998 ffffffff810c8c93 ffffc90025d4fa50
Sep 25 14:12:51 yggdrasil kernel: Call Trace:
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff813a4a1b>] dump_stack+0x61/0x7e
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810c8b8d>] bad_page+0xf3/0x10f
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810c8c93>] check_new_page_bad+0x74/0x76
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810cb2f0>] get_page_from_freelist+0x760/0x78f
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810cb74a>] __alloc_pages_nodemask+0x124/0xc71
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81117aef>] ? get_mem_cgroup_from_mm+0x9c/0xa4
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff8111cc16>] ? memcg_kmem_get_cache+0x5c/0x189
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff813a959e>] ? __radix_tree_lookup+0x2b/0x86
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff813a9609>] ? radix_tree_lookup_slot+0x10/0x20
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff813a8fed>] ? radix_tree_tag_set+0x6e/0x93
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81102d82>] alloc_pages_current+0xbe/0xe8
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810c4d78>] __page_cache_alloc+0x89/0x9f
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810c4ecc>] pagecache_get_page+0x13e/0x1e6
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff810c4f8f>] grab_cache_page_write_begin+0x1b/0x32
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff8116438d>] iomap_write_begin+0x6f/0xef
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff811645eb>] iomap_write_actor+0x96/0x14b
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81164a69>] iomap_apply+0x9f/0xf0
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81164b06>] iomap_file_buffered_write+0x4c/0x70
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81164555>] ? iomap_write_end+0x5d/0x5d
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff8129e4a3>] xfs_file_buffered_aio_write+0xc8/0x1e3
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff8129e651>] xfs_file_write_iter+0x93/0x11b
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81121078>] __vfs_write+0xc3/0xec
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff81121a5f>] vfs_write+0xcd/0x176
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff8112273a>] SyS_write+0x49/0x83
Sep 25 14:12:51 yggdrasil kernel: [<ffffffff8167f537>] entry_SYSCALL_64_fastpath+0x1a/0xa9

 

After seeing this I'm worried about file/disk integrity and whether something might have gotten corrupt, on top what caused it in the first place. I spot checked through the files I was moving at their new location and they seem to playback and parse when jumping around without problems, so I'm hoping they are ok. 

 

Also it seems about the same time it crashed my Plex VM (migrated from hyper-v to unraid VM, haven't had a chance to migrate to a proper docker container yet, so it is still just a centos7 vm) that also resides on the cache pool. Got a message from a person that uses my Plex shortly after the errors above and sure enough I checked and the VM had suddenly been stopped. Not entirely sure it is related, but seems very suspect.

 

So, questions I'm wondering about:

- My above question about moving stuff around within the /mnt/user context at CLI, should that respect the cache yes/no/only settings? It appears it does not.

- Any idea what caused the "referenced|dirty" errors, what did I do wrong? Should I mv files around in another way? I guess I could do it via a Windows computer connected to the shares, but that is so inefficient since it basically has to pull the file to my system and copy it back, both over the network, whereas it should be much quicker doing it directly on the unRAID system. I guess as a compromise I could do it via the docker's CLI, where it sees those location as completely separate file systems and which won't be quite as fast as native but pretty decent since it be within the docker network, right?

- Do I need to worry about disk or file corruption due to the above and if so where would I check?

- Is it a Bad Idea(tm) to have downloads go to the cache pool where dockers and VMs are running? Is this going to continue to cause long term and continuing issues and headaches?

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.