Am Donnerstag, 29. Dezember 2011 schrieb Li Zefan: > Martin Steigerwald wrote: > > Hi! > > > > With 3.2-rc4 (probably earlier), Ext4 seems to remember what areas it > > trimmed: > > > > merkaba:~> fstrim -v /boot > > /boot: 224657408 bytes were trimmed > > merkaba:~> fstrim -v /boot > > /boot: 0 bytes were trimmed > > > > > > But BTRFS does not: > > > > merkaba:~> fstrim -v / > > /: 4431613952 bytes were trimmed > > merkaba:~> fstrim -v / > > /: 4341846016 bytes were trimmed > > > > > > Is it planned to add this feature to BTRFS as well? > > There's no such plan, but it's do-able, and I can take care of it. > There's an issue though. > > Whether we want to store TRIMMED information on disk? ext4 doesn't > do this, so the first fstrim will be slow though you've done fstrim > in previous mount. > > For btrfs this issue can't be solved without disk format change that > will break older kernels, but only 3.2-rcX kernels will be affected if > we push the following change into mainline before 3.2 release. I can´t comment on the disk format change. But if it is accepted, I can give your patchset a spin before 3.3 merge window. Tell me when you´d like that. If not, then AFAIK there is another disk format change necessary to raise hard link limit. So maybe then it makes sense to combine both disk format changes at some future kernel. Better an early one, before adoption raises even more. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
