On Saturday, 17 December, 2011 12:54:47 you wrote: [...] > > This reminds me of the delayed allocation discussion as Ext4 introduced > that feature. > > Ext3/4 developer Theodore T´so said if the applications are not using > fsync() its their fault. But before OTOH applications began to avoid using > fsync() since it has had serious performance drawbacks on ext3 (not ext4) > with data=ordered. > > Ext4 now has workarounds for the rename and truncate cases, after Linus > requested boldly to not break existing userspace. IIRC the problem was data loss. Instead you was blaming (correctly) a slowness problem. Are two very different problem. > Now applications that use fsync() the way Theodore T´so and other see it > correctly used should now skip the fsync() on a BTRFS? I never say to not use the fsync() call. I am only arguing that for a package manager the fsync() call is not the best API. The package manager were designed with capabilities of the old file-systems in mind. At the time the sync(2) API was the only available. With this API it is impossible to have an atomic upgrade (all or nothing) of a package. With the new filesystems (BTRFS and ZFS ), the package manager have more options. They can create a snapshot at the beginning (of the old filesystem) and rollback if something goes wrong (I am simplifying a bit) . But the package manager have to be updated. As bonus you can avoid to use sync(2) which has performance drawbacks (specially with BTRFS). [...] > > > Using the snapshot during an upgrade open a lot of possibility which > > are not allowed with EXT4. With snapshot you can always go back if > > during an upgrade if something goes wrong (like strange packages > > dependencies). Or you can have the previous configuration to go back > > in case of trouble. > > 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. [....] > > Thanks, Regards -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@xxxxxxxxx> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
