GNU bug report logs - #11761
Slight bug in split :-)

Previous Next

Package: coreutils;

Reported by: Jim Meyering <jim <at> meyering.net>

Date: Thu, 21 Jun 2012 22:16:02 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 11761 <at> debbugs.gnu.org
Subject: bug#11761: Slight bug in split :-)
Date: Fri, 22 Jun 2012 20:26:54 +0100
On 06/22/2012 08:09 PM, Paul Eggert wrote:
>>From a filesystem point of view, would it be
> more efficient to invoke ftruncate at the end of
> writing, rather than at the beginning?  That way,
> if the file already exists and is of the right size,
> it won't need to be reallocated.  We're not trying
> to write any holes, so this optimization should be
> valid.
> 
> Please don't let this comment slow you down, as your
> patch is fine as-is.  I'm mainly asking because I was
> wondering about the issue in general.

Hmm, I suppose at the writing stage, truncating
after writing could be more efficient.

Though if we're updating a split set,
and the new set had some new files, then the new split set
could be more likely be on separate parts of the disk,
hence slowing future processing of the split set?

You could also argue that you should free up as
much place as possible and let the file system
decide where best to allocate stuff, which can
change over time.

I'd err on the side of simplicity here.

cheers,
Pádraig.




This bug report was last modified 13 years and 22 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.