On Wednesday 07 January 2009 07:21, OGAWA Hirofumi wrote: > Daniel Phillips <[email protected]> writes: > > >> Filesystem freeze : > >> Get an utility that flush cache and return something when it's done, then > >> freeze IO on disk and throttle/stack in a memory buffer until it's full. > >> When it's full, return again something and resume normal operation, or > >> freeze IO until we ask to resume. This in order to take clean snapshots > >> when > >> backend support versionning. Even if it's not necessary due to tux3 design, > >> it would be nice to be able to do it in order to ensure that some IO are > >> commited to disk, then get some time to do something to the disk backend, > >> with no impact on the filesystem side. > > > > I think all you want there is the ability to treat a snapshot as a > > barrier: user asks for a snapshot, Tux3 starts a new delta and sets a > > flag on it; when that snapshot has committed, the snapshot request > > is acknowledged. That way, the user gets a snapshot of what has been > > sent to the filesystem most recently, without needing to stall the > > filesystem throughput. > > > > Tux3 does not need a new memory buffer for this, the needed mechanism > > is just what has already been designed. > > FWIW, if it is needed, we just implement ->write_super_lockfs nad unlockfs. > And I guess it shouldn't be hard.
Yes, we will support lock/unlockfs. I think he was asking for something a little different. IO is supposed to continue to memory while block IO is prevented, to take a clean snapshot. We can do that better. I think What he really wants is for the snapshot to include the most recent changes, and not stall the filesystem. lockfs causes a big stall and danger of system lockup too. What we can provide instead is a command to set a new delta that carries a new volume version. All changes after that delta belong to the next snapshot. When the delta that carries the snapshot completes to disk, the snapshot setting command returns. This way, the user gets exactly what they expect: whatever they wrote before the snapshot ends up on disk. And the only thing that stalls is the snapshot command: if there is parallel IO on the filesystem, it will continue and belong to the next snapshot. Contrary to popular belief, lockfs does not make snapshots "clean". Parallel application IO can be interrupted at any point by lockfs. There is nothing clean about that. The only way to make a clean snapshot with respect to application IO is for applications to be aware of the snapshot interface and prepare themselves accordingly. Because there is no standard interface, no applications do that. So lockfs does not produce any cleaner results than just taking a snapshot at some random time. What it does do, is flush dirty cache to disk before the snapshot. Another way to do that is sync(1), without danger of system lockup. So I don't know what lockfs is actually supposed to accomplish. Regards, Daniel _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
