On Wed, 15 Jul 2009 16:40:58 -0400 (EDT)
John Garvey <community-noreply@qnx.com> wrote:

> Will Miles wrote:
> > -> A cluster is freed up near the beginning of the FAT.  This must
> > reset the hint, because:
> > -> The next file write causes a FAT scan starting from the freed
> > cluster. This can involve tens of thousands of block reads to get back
> > to the end of the used area.
> 
> Yes, the hint is reset.  There is no pending change to this behaviour,
> although you can obviously construct some degenerate scenarios where
> immediately re-using clusters is good or bad :-/

Alas, it would seem our recording engine is one of them. :(

> 
> > Unfortuantely, though, in the short term I do need a fix for this - we
> > don't have enough RAM to buffer our data output for the 10+ seconds it
> > takes for the scan to complete while reading single blocks (not to
> > mention the havoc it causes to our UI when the system wanders off at
> 
> Have you considered pre-growing the files?  With DCMD_FSYS_PREGROW_FILE
> this is very fast (one chunk of FAT/bitmap allocated all at once,
> data blocks not zero-filled, subsequent writes are then over the top
> of allocated blocks with no additional FAT access required).  It does
> require that you be able to recognise how much of the written data
> is valid in case of powerfail (before you get a change to ftruncate
> it back to the real size if you guessed wildly big).  A logfile or
> data capture you might be able to extend in large chunks as you fill.
> Hmm, although as the same allocation scan is used, it too will be
> fooled by delete fragmentation resetting the hint.

We did try a pre-allocation system in the past, if only to reduce
filesystem wear.  We were quickly shot down by our users who were
annoyed at both not being able to tell how much data was actually
recorded by the file size, as well as having to copy significantly more
data in the event of early termination.  Our current recording format
uses a COTS database engine which, while it's technically possible to
do some preallocation, would suffer from the same basic problem except
internal to the database (scanning for the next 'free' entry).

But you're right, even with a preallocation scheme, every time a new
filesystem allocation is performed it will still suffer from the
FAT-scan performance hit; the only real difference would be that we can
more precisely predict when those hits will occur.

> 
> > priority 21). Would you recommend I try to implement some read-ahead
> > logic, or would it be simpler to just not change the hint when
> > shrinking a file?
> 
> So, you can disable the hint reseting (in dos_makesmaller()).  The
> side-effect will be a sequential pass right through to the end of
> the partition (or you reboot/remount).  The end of the disc is
> slower than the beginning (property of HDD) and many factory-
> formatted USB sticks use a canned fsys which doesn't actually fit
> on the partition (so will try to use non-existent clusters).

OK - I'll give that a try.  I think the loss in performance at the end
of the drive will have less real-time impact on our system than the FAT
scans do.  I'm not too worried about invalid partitions; our
policy is always to repartition and reformat our recording drives
ourselves before deploying them to the field.  Unfortunately we haven't
had much success with recording to USB sticks either, but that's an
unrelated problem - devb-umass just keeps locking up altogether (on
four totally different USB devices, including a USB->SATA adapter). We
haven't followed up on that since we're still using 6.3.2; if we still
run into it when we get to 6.4.x, I'm sure you'll hear back from us
then.. :)

> 
> I can't think of any other short-term solution. ...