On 07/22/2014 04:53 PM, Chris Mason wrote:
On 07/19/2014 02:23 PM, Martin Steigerwald wrote:
Running 3.15.6 with this patch applied on top:
- still causes a hang with `rsync -hPaHAXx --del /mnt/home/nyx/ /home/nyx/`
- no extra error messages printed (`dmesg | grep racing`) compared to
without the patch
I got same results with 3.16-rc5 + this patch (see thread BTRFS hang with
3.16-rc5). 3.16-rc4 still is fine with me. No hang whatsoever so far.
To recap some details (so I can have it all in one place):
- /home/ is btrfs with compress=lzo
BTRFS RAID 1 with lzo.
- I have _not_ created any nodatacow files.
Me neither.
- Full stack is: sata <-> dmcrypt <-> lvm <-> btrfs (I noticed others
mentioning the use of dmcrypt)
Same, except no dmcrypt.
Thanks for the help in tracking this down everyone. We'll get there!
Are you all running multi-disk systems (from a btrfs POV, more than one
device?) I don't care how many physical drives this maps to, just does
btrfs think there's more than one drive.
-chris
Hi,
In case it's interesting:
From an earlier email thread with subject: 3.15-rc6 -
btrfs-transacti:4157 blocked for more than 120
TLDR: yes, btrfs sees multiple devices.
sata <-> dmcrypt <-> btrfs raid10
btrfs raid10 consist of multiple dmcrypt devices from multiple sata devices.
Mount: /dev/mapper/sdu on /mnt/storage type btrfs
(rw,noatime,space_cache,compress=lzo,inode_cache,subvol=storage)
(yes I know inode_cache is not recommended for general use)
I have a nocow directory in a separate subvolume containing vm-images
used by kvm.
The same kvm-vms are reading/writing data from that array over nfs.
I'm still holding that system on 3.14. Anything above causes blocks.
--
Torbjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
