deusxanime Posted September 25, 2017 Share Posted September 25, 2017 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? Quote Link to comment
Recommended Posts
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.