On Tue, 11 Jul 2006 17:04:56 PDT, Hans Reiser said: > There are legitimate applications where the value of data is low enough > and the load is high enough, that losing the database upon crash is ok. > > I have mixed feelings about making it a mount option for reiser4 because > many users will not know what they do. In the end though, I should just > sell the rope and advise but not control what people do with it. If > someone writes it I will take a mount option patch to disable fsync iff > it comes with documentation that has a lot of warnings.
Two things to consider before writing code: 1) Should it be done at the VFS level instead of in the filesystem? Architecturally, it might be better there, so it applies to ext3 and jfs and others too... 2) Alternatively, should it be done on a per-file basis (possibly flagged with a chattr or similar)? It can't be done as an open() flag or ioctl(), because you're trying to override what the code does... That way, you can mitigate any fsync() load caused by one file, and still not leave yourself open to being screwed by some other application that tries to fsync() in other directories on that filesystem. It would be Really Bad if /home/fred/db23.sqlite gets corrupted because the filesystem was mounted -nofsync because of /home/george/moby.sqlite overhead....
pgpVCab4SeTph.pgp
Description: PGP signature
