Re: vim file write mode on journaling fs.

[Russell Cattelan <cattelan@thebarn.com>]

Bram Moolenaar wrote:

> Russell Cattelan wrote:
>
> > > The following script was used.
> > >
> > > #!/bin/sh
> > > echo Test > file1
> > > cp file1 file2
> > > rm file1
> > >
> > > When the script completes I hit the big red switch and sure enough.
> > > After recovery the file1 does not exist (that is ok) but file2 is
> > > empty and does not have data but it does have a size of 5 bytes.
> > >
> > > So something is biting us. I would expect file2 to be non existant
> > > (because it didn't get written yet or the correct file. This is in
> > > between.
>
> I'm glad Seth found an example with basic commands which shows Vim isn't
> really doing something strange.
>
> > Actually this is exactly what should happen.
> > The remove transaction was commited to log before the rm returned
> > (probably) upon running recovery at mount time the log was replayed and the
> > delete recorded in all appropiate meta data.
> >
> >
> > File2 was created and committed to disk thus creating an inode with 0 bytes,
> > cp then came along and wrote 5 bytes to the file, which ofcourse is was
> > allocated "delayed"
> > by default BUT the size update (being not logged... see previous email)
> > was written directly
> > to the inode, now you have an inode with size but no extents.
> > Normally the flush daemons eventually come along and convert all
> > "delayed" allocations
> > to real extents and write them to disk, but when you wack the power
> > before this happens
> > you end up with a file with no extents thus a "hole".
> >
> >
> > This is not an inconsitency in the FS just an inconsitency in file data,
> > which as we all know is not something that can be guarenteed without data
> > logging.
>
> Of course I wouldn't expect data to be restored when I switch off a system
> while it's busy with something.  But when I copy a file, wait a couple of
> seconds and then switch off the system, there is no reason the file is
> gone.  That the FS causes reordering of disk actions is understandable,
> but it should take care that the negative effects of this are minimized.  It
> should detect that the disk isn't doing anything and that there is a perfect
> chance to start writing dirty data in the cache.  A fixed timeout of 30
> seconds or even 1 second sounds like a lazy programmer that didn't want to
> implement a satisfactory solution.

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.



>
>
> Summary: I consider this to be a problem with the filesystem, not with Vim.
> For people that want to be sure their file is synced, the ":!sync" command can
> be used.
>
> --
> I'm sure that I asked CBuilder to do a "full" install.  Looks like I got
> a "fool" install, instead.              Charles E Campbell, Jr, PhD
>
>  ///  Bram Moolenaar -- Bram@moolenaar.net -- 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  ///

--
Russell Cattelan
cattelan@thebarn.com