|To:||Seth Mos <knuffie@xxxxxxxxx>|
|Subject:||Re: vim file write mode on journaling fs.|
|From:||Russell Cattelan <cattelan@xxxxxxxxxxx>|
|Date:||Fri, 10 Aug 2001 16:56:54 -0500|
|Cc:||Bram Moolenaar <Bram@xxxxxxxxxxxxx>, Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802|
Seth Mos wrote:
At 22:43 10-8-2001 +0200, Seth Mos wrote:
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: vim file write mode on journaling fs., Colin Walters|
|Next by Date:||TAKE - set inode ops in xfs_attrctl_by_handle, Eric Sandeen|
|Previous by Thread:||Re: vim file write mode on journaling fs., Seth Mos|
|Next by Thread:||Re: vim file write mode on journaling fs., Bram Moolenaar|
|Indexes:||[Date] [Thread] [Top] [All Lists]|