On Fri, 10 Aug 2001, Bram Moolenaar wrote:
> Seth Mos wrote:
>
> 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.
It was completely idle and no disk IO at all.
> > >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.
Well, if I am correct the VM should push harder. But this would be masking
the problem.
> > 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).
One sync exit wouldn't make that much of difference, You can only exit a
program once :-)
> 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?
I don't know but the swapfile had not the changes but was a exact copy of
the same file.
> 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).
So the deletion of the swap file probably is buffered. That might be the
reason it was not deleted. Although XFS uses synchronous delete
operations.
> 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.
The thing is that the only application that people have managed to
produce NULL character files with so far has been vim :-/
If I edit a file with pico it is in one piece if I save it. I will
scavenge the pine sources to see what pico is doing.
No others files on the system are damaged in this same way.
> > 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.
Weird eh.
Cheers
Seth
|