On 2012-05-14, at 9:27 AM, David Sterba wrote: > On Mon, May 14, 2012 at 02:08:52PM +0200, David Sterba wrote: >> Seems more like a bug, let's narrow down the conditions before we look >> into the code. > > And already known bug (with a proposed fix, cc'd author): > > http://www.spinics.net/lists/linux-btrfs/msg15195.html > > Quoting: > > # mkfs.btrfs /dev/sda1 > # mount /dev/sda1 /mnt > # mkdir /mnt/1 > # cd /mnt/1 > # btrfs subvolume snapshot /mnt snap0 > # ll /mnt/1 > total 0 > drwxr-xr-x 1 root root 10 Jun 30 15:01 1 > ^^^ > # ll /mnt/1/snap0/ > total 0 > drwxr-xr-x 1 root root 10 Jun 30 15:01 1 > ^^^ > It is also 10, but... > # ll /mnt/1/snap0/1 > total 0 > [None] > # cd /mnt/1/snap0/1/snap0 > [Enter a unexisted directory successfully] > --- > > Though there's a difference, that in your listing the @working (here > it'd be snap0) is present. > > > david
Thanks David, Yes, it's looking similar, but perhaps not identical. I checked, and the "@working" directory inside the new snapshot has inode 2. The phantom directory shows up on ls, and can be removed by rmdir. However: since I sent the first email, I moved one of the volumes to btrfs RAID1 from btrfs single on top of md raid. I recreated the filesystem (mkfs.btrfs -L reaper -m raid1 -d raid1 /dev/sdc1 /dev/sdd1) at that time, and restored data from a backup. The new filesystem is not displaying the issues from before; it is now behaving in-line with the SSD I mentioned in my first post, which was similarly set up from the command line with mkfs.btrfs. The disks that *are* still showing the subdirectory creation issue were both converted from ext4 (using old tools). So perhaps that's a direction to explore. Thanks for the help. Cheers, Brendan
smime.p7s
Description: S/MIME cryptographic signature
