Am Samstag, 17. Dezember 2011 schrieb Goffredo Baroncelli: > > Adding new possibilities is one thing. And supporting snapshots > > properly would depend on some support side from the applications. I > > think that using snapshots for upgrades is a good idea. > > > > > > > > But OTOH I think that BTRFS should not break or slow down existing > > userspace. I think that existing approaches like using fsync() like > > according to quite some filesystem developers it should be used > > should continue to work nicely. > > Nobody wants to slowdown the application. But the life is full of > compromises. If you want the speed of ext4, you can use ext4. If you > want the snapshot capability and the COW guarantee you can use BTRFS, > but you have some slowness. > > Of course the best would be have the speed of the ext4 with the > capabilities of btrfs.... :-) Unfortunately today this is not > available.
Its perfectly acceptable for me that BTRFS does not deliver this yet. I understood your initial answer that its just that BTRFS is different and thus performs poorly in fsync() based workloads and thats about it. That its a principal issue. That part I didn´t agree too. Heck from the design differences of COW filesystem it might even be some sort of a principal issue. But then I like to see this as a challenge, not as a show stopper. Actually for me especially for that Amarok Thinkpad T23 there is no hurry. Its play BTRFS play machine. I just want to see what I can do with filesystem maintenance to bring it up to speed. Everything else is following development and upgrading kernels ;). 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
