[Top] [All Lists]

Re: is the flush-on-close-after-truncate still needed?

To: DS <xfs@xxxxxxxxxxxx>
Subject: Re: is the flush-on-close-after-truncate still needed?
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 26 Jun 2008 16:19:39 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20080626210904.GA15920@xxxxxxxxxxxx>
References: <4859415B.3000009@xxxxxxxxxxx> <200806181049.07812.dchinner@xxxxxxxxx> <20080626210904.GA15920@xxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (X11/20080501)
DS wrote:
> Hmm, but file overwrite in perl/php is slow, very slow.

If you have control over your perl/php, perhaps you can change it to do
unlink/create/write instead of truncate/write?


> Which FS is best for me?
> XFS - perl/php overwrite problem
> EXT3 - 32000 subdirs limit
> REISER - no future
> JFS - ?
> DS
> On Wed, Jun 18, 2008 at 10:49:07AM -0700, Dave Chinner wrote:
>> On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote:
>>> After Lachlan's fix to separate on-disk and in-memory sizes, and only
>>> update on-disk when data is on-disk
>>> (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the
>>> XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed?
>> Yes, because waiting 30s before writing back /etc/fstab after it
>> has been modified will result in lots of bug reports of /etc/fstab
>> being zero length after a crash instead of being full of NULLs.
>> We have had very few reports of zero length files or files with
>> NULLs since this change was made (regardless of the file size 
>> update ordering changes). i.e. if we remove this code then the
>> common case where NULL files occurred will return - only this
>> time as zero length files.
>> Cheers,
>> Dave.

<Prev in Thread] Current Thread [Next in Thread>