Am Samstag, 17. Dezember 2011 schrieben Sie: > On Friday, 16 December, 2011 20:53:58 Martin Steigerwald wrote: > > > I found a solution, but requires a bit of setup. > > > > > > > > > > > > The idea is to avoid do perform sync during the package > > > installation. In order to avoid data loss in case of failure, I > > > create a snapshot before the upgrading. If something goes wrong > > > (i.e. a power failure) I rebooot the system from the snapshot. If > > > the installation finish without problem, I flush all the data to > > > the disk and remove the snapshot. > > > > > > > > > > > > For the detail, see a my old post titled "[RFC] aptitude & BTRFS > > > slow" (2011-10-19) > > > > Sounds more like a workaround to me than a solution. > > Sorry but I strongly disagree. > > Aptitude was designed for an ordinary filesystem. Where the only way to > have a filesystem consistency is to issue a lot of sync for every > package. But this doesn't prevent to have an half package > installed:(think about to an "openoffice" upgrade: in case of power > failure, you could not have nor the old openoffice, nor the new one. > Instead with the snapshot you can always have the old system or the new > system. No half packages > > With BTRFS, I can say that the workaround[*] is using the sync and not > the snapshot > > The true is that BTRFS is different from ext4 (or ext3, xfs....). You > can use BTRFS like ext4 and you will find a lot of regression like > this. > > BTRFS is very different from an ordinary filesystem, and you have to > change some behaviour to take advantages with is peculiarities.
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. 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 find it *highly* problematic when applications are required to adapt their behavior depending of the filesystem being in use. This just doesn´t make sense to me. If BTRFS has other means to guarantee filesystem consistency that is faster it might still make fsync() a no-op or just creating a snapshot temporarily automatically. > 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. Similar goes for the hardlink limit. > [*] Of course this is due to the fact that the most part of the > filesystem is like ext4. Supporting BTRFS could be not the highest > priority. I do think that a if fs=ext4 then do this if fs=btrfs then do this and if fs=ext3 + data=ordered then do this if fs=ext3 + data=ordered + kernel=whatnot then do it a tad bit differently if fs=unkown then assume this in a application is just kind about broken and always thought that one main task of a filesystem would be to lift off the burden on the details on how data is saved from the application. Ok, some guidelines might be needed like if you save 10 bytes 1000 times it might be less performant than saving 10000 bytes at once, but aside from that… So I think BTRFS should have a fast fsync - that fullfils the consistency guarentee by whatever compatible way it sees fit - and for the system partition I would even trade in the cow functionality. I didn´t have it with Ext4 anyway. 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
