Hi All, I'm experiencing some odd-seeming behaviour with btrfs on Ubuntu 12.04, using the Ubuntu x86-64 generic 3.2.0-24 kernel and btrfs-tools 0.19+20120328-1~precise1 (backported from the current Debian version using Ubuntu's backportpackage). When I snapshot a subvolume on some of my drives, it creates an empty directory inside the snapshot with the same name as the original subvolume. Example case and details below:
---- root@zeus:/mnt/reaper-all# ls 2012-05-03 @working root@zeus:/mnt/reaper-all# ls @working documents games MeganMusic misc-docs photos vm Downloads isos MeganPhotos Network Trash Folder Temporary Items workdir Dropbox iTunes MeganUBC otherphotos videos root@zeus:/mnt/reaper-all# btrfs subvolume snapshot @working test Create a snapshot of '@working' in './test' root@zeus:/mnt/reaper-all# ls test/ documents games MeganMusic misc-docs photos vm Downloads isos MeganPhotos Network Trash Folder Temporary Items workdir Dropbox iTunes MeganUBC otherphotos videos @working root@zeus:/mnt/reaper-all# ls test/@working/ root@zeus:/mnt/reaper-all# btrfs subvolume list . ID 257 top level 5 path @working ID 258 top level 5 path 2012-05-03 ID 263 top level 5 path test ---- The preceding volume is mounted with "rw,compress" on top of LVM on md raid1, and I get the same behaviour from another volume running directly on a gpt partition. In both cases, the volumes are 1 TB btrfs with default creation parameters, and were converted from ext4 using btrfs-convert (with the Ubuntu 0.19+20100601 version, before switching btrfs-tools to version 0.19+20120328). As far as I am able to tell, both filesystems are healthy. The drives are exported to some Mac OS systems via netatalk, which leads to some odd directories, but AFAIK shouldn't affect much else. The subdirectory under the snapshot is just that (i.e., a directory and not a subvolume). I don't see this behaviour on either the "@" or "@home" subvolumes of the system SSD (conforming to the Ubuntu btrfs layout), which are mounted "rw,noatime,discard,subvol=@" and "rw,noatime,discard,subvol=@home". However, the btrfs volume on the SSD was built without btrfs-convert. It's an Intel 520 with Sandforce controller, which is why I'm not using -o compress in this case. I haven't confirmed one way or the other if it is an issue of -o compress, but can do a test reboot with different options if that will help. Could anyone shed some light on what's going on? If it's simply an issue with out of date btrfs-progs, I can either live with it or upgrade. However, I'd rather not track the bleeding edge on this system if I can avoid it. Thanks! All the best, Brendan Smithyman
smime.p7s
Description: S/MIME cryptographic signature
