[EMAIL PROTECTED] wrote: >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... > Yes, if the below is not done.
> > >2) Alternatively, should it be done on a per-file basis (possibly >flagged with a chattr or similar)? > Once the pseudofiles interface or sys_reiser4() are debugged and working, yes. > 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.... > >
