[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vim file write mode on journaling fs.
Seth Mos wrote:
> >Calling fsync() after writing a file would reduce the chance to lose data,
> >but it also makes Vim slower and increase the system load.
>
> Is there an option within vi to use this as a "Safe mode".
Not at the moment.
> Observation has revealed that the data is only pushed out to disk after 30
> seconds or so by the VM. The metadata (size and timestamp) was pushed out
> to disk on exit.
30 seconds? Quite a big chance to accidentally switch off the machine then.
Why doesn't it write the data out within a second or so? Assuming the
harddisk is idle.
> >When Vim exits the file has already been closed. It would have to be done
> >each time you write a file, just before closing it. It actually doesn't
> >matter if you exit Vim or not, you might just use ":w" when you go off for
> >lunch and trip over the power cord.
>
> This produces the exact same pattern.
> I opened minicom.log which had one line of text and was 35Bytes.
> Added a line "test"
> wrote it with :w
> unplug.
I suppose you do this while the system isn't busy with other things. The FS
should be smart enough to use this idle time to start writing data to the disk.
> After reboot the file is:
>
> [seth@lsautom seth]$ ll minicom.log
> -rw-r--r-- 1 seth staff 42 Aug 10 17:37 minicom.log
>
> [seth@lsautom seth]$ cat -v minicom.log
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[seth@lsautom
> seth]$
>
> So the metadata was written but the data never got there.
And the old data also isn't there. I suppose the FS assigns another disk
block to the file. That is actually part of the problem: The FS flushes the
meta data, and thereby clears the file. Until the time the data is actually
written, you have a very big danger of losing your data. I would call this
"taking a risk" in the FS. The time between the writing of the meta data and
the file contents should be minimized to reduce the risk.
> vi -r minicom.log did contain the valid data. So why was the .swp written
> out but the original file not!
The swap file is synced, because Vim assumes that using the original file plus
the swap file is enough to restore the text at the point you are editing. The
swap file only stores the changes, thus it wouldn't need to be as big as the
original file (unless you do a ":preserve" or Vim discovers the original file
is gone). Thus syncing the swap file is less of a performance hit (on
average).
I wonder why the swap file wasn't deleted. Vim must have deleted it, and if
the metadata for the text file was flushed, why wasn't the swap file metadata
flushed?
Vim assumes that as soon as the file has been written, it's safe to delete the
swap file. And when you didn't set the 'backup' option, the backup file is
also removed at that point. For when you have a "risky" FS a sync would
indeed be useful. Or make sure you use a backup file (although, if you write
the file twice within those 30 seconds the backup file probably also isn't
useful).
I doubt that adding the sync in Vim will be that helpful. You have the same
problem with doing "cp" and then deleting the original file. In fact, any
program that writes a file would run into this problem. Are you going to
suggest every relevant application has to call fsync()? You might want to add
a call to fsync() inside close(). Well, wouldn't need it for temp files.
> calling sync manually after exit gets it to disk for sure.
>
> Waiting 10 seconds before pulling the power was not enough to get it to disk.
That should be solved by the filesystem. Doesn't make sense to keep dirty
data while the system is idle.
--
A computer programmer is a device for turning requirements into
undocumented features. It runs on cola, pizza and Dilbert cartoons.
Bram Moolenaar
/// 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 ///