Bram Moolenaar wrote:
> Russell Cattelan wrote:
> > This isn't a matter of laziness or poor design it's a trade off.
> > If you want the benefits of delayed allocation/write then there has to
> > be a DELAY otherwise there would be much point,
> > if you want better data integrity in the event of a crash
> > then mount your filesystems O_SYNC and loose the performance.
> There is no need for such a trade-off. It is not difficult to detect that the
> harddisk isn't very busy and start writing out dirty data blocks then. This
> doesn't cause a performance drop and greatly increases reliability.
You have the scenario backwards, the idea of delayed allocation/write is
to reduce the amount of disk activity and to aggregate disk writes together
thus by making disk transfers more efficient. The is no way for the
to predict the type of IO a user app is going to do, streaming, random, fast
slow random... the kernel and FS make best guess real world average behavior
predictions. Everything is tune able of course but that requires the person
running the app understands the app's io behavior.
> It's certainly worth the effort to implement this.
It is implemented it's called O_SYNC.
> The tests done by Seth
> show that this is a real, existing problem.
Every file system that does buffering has this problem XFS included.
> Don't look at this from the point of view of a person that knows what "delayed
> allocation/write" means, look at it from the point of view of a user.
Maybe so but as a user sometimes you must understand your system to
understand why it does things, and not assume it's a bug.
> f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng
> /// Bram Moolenaar -- Bram@xxxxxxxxxxxxx -- http://www.moolenaar.net \\\
> ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
> \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///