ts-7000
[Top] [All Lists]

Re: [ts-7000] Solving the USB drive journalling issue please criticize

To:
Subject: Re: [ts-7000] Solving the USB drive journalling issue please criticize
From: Jim Jackson <>
Date: Tue, 19 Sep 2006 17:16:44 +0100 (BST)


On Tue, 19 Sep 2006, Dave Cramer wrote:
> On 19-Sep-06, at 9:37 AM, Jim Jackson wrote:
> > On Mon, 18 Sep 2006, Dave Cramer wrote:
> >
> > > Here's the problem:
> > >
> > > Customer needs to be able to just plug, and unplug USB drive WITHOUT
> > > unmount, or sync.
> > >
> > > The drive is being used to log data.
> > >
> > > I was thinking about doing write ahead logging, but then it occurs to
> > > me that the only issue with disk corruption is when re-arranging the
> > > structure of the disk
> > >
> > > ie doing deletes, creating, removing directories
> > >
> > > So my idea is to simply create n files named 0001-nnnn where n is the
> > > size of the flash/size of each file before hand and then simply write
> > > into those files.
> > > My expectation is that the worst thing that will happen is I will
> > > lose one file worth of data if it is pulled out before synching the
> > > disk.
> > > I' will also write 0's to the files before putting the data on them.
> > >
> > I'm not so sure that precreating the files etc will help. You'd really
> > need to look at the details of how the particular filesystem you
> > are using
> > write to and extends files.
> My intention is to never extend the file, simply write over what is
> there

I starting thinking that maybe the best would be to treat a partition as a
raw block device, and simply write sequential blocks with the data.
If the partition was prewritten with a byte seq that was erased by the
data, you'd be able to read until that seq. was found.

But then thinking about this problem further, it is even less predictable
than simply looking at what you'd expect from a file system (or even a raw
block device)  and what the kernel does. There is the extra layer of
complexity formed by the flash controller and any wear levelling etc it
does under the hood.

The kernel may just have written a block and got an ack. from the stick,
but internally the stick has probably just buffered the data, and will be
doing goodless knows what before finding the correct block to write the
data to. You'll never know what flash controller, and even if you did, I
understand many manufacturers don't even document what their controllers
do. You have to trust that there's an internal capacitor and it stores
enough to allow the controller to complete the write even if the stick is
pulled at the most inopportune moment.

I wish you well. If you have time I'd be interested in an outline of what
you end up doing and how it performs in practice.

cheers
Jim


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
     
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



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

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU