Message-ID: <3B7458A6.7020202@thebarn.com>
Date: Fri, 10 Aug 2001 16:56:54 -0500
From: Russell Cattelan <cattelan@thebarn.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: Bram Moolenaar <Bram@moolenaar.net>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: vim file write mode on journaling fs.
References: <200108101958.f7AJwmv07495@moolenaar.net> <4.3.2.7.2.20010810231323.03370de0@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:

> At 22:43 10-8-2001 +0200, Seth Mos wrote:
>
>> > Does it only happen when overwriting an existing file?  I would 
>> expect the
>> > same to happen when writing a new file.  E.g. when using:
>>
>> I asume this is the case.
>>
>> >       cp file1 file2
>> >       rm file1
>> >
>> > Could you end up with an invalid file2 while file1 has been deleted 
>> already?
>
>
> 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. 

>
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.