On 05/25/2012 09:10 PM, Alexander Block wrote: > Just to show some numbers I made a simple test on a fresh btrfs fs. I > copied my hosts /usr (4 gig) folder to that fs and checked metadata > usage with "btrfs fi df /mnt", which was around 300m. Then I created > 10 snapshots and checked metadata usage again, which didn't change > much. Then I run "grep foobar /mnt -R" to update all files atime. > After this was finished, metadata usage was 2.59 gig. So I lost 2.2 > gig just because I searched for something. If someone already has > nearly no space left, he probably won't be able to move some data to > another disk, as he may get ENOSPC while copying the data. > > Here is the output of the final "btrfs fi df": > > # btrfs fi df /mnt > Data: total=6.01GB, used=4.19GB > System, DUP: total=8.00MB, used=4.00KB > System: total=4.00MB, used=0.00 > Metadata, DUP: total=3.25GB, used=2.59GB > Metadata: total=8.00MB, used=0.00 > > I don't know much about other filesystems that support snapshots, but > I have the feeling that most of them would have the same problem. Also > all other filesystems in combination with LVM snapshots may cause > problems (I'm not very familiar with LVM). Filesystem image formats, > like qcow, vmdk, vbox and so on may also have problems with atime. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Did you run the recursive grep after each snapshot (which I would expect would result in 11 times as many metadata blocks, max 3.3 GB), or just once after all 10 snapshots (which I think would mean only 2x as many metadata blocks, max 600 MB)? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
