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. Thanks. -- OGAWA Hirofumi <[email protected]> _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
