Re: Need to remove a ghost file, but can't because it doesn't exist
On Tue, Nov 21, 2006 at 10:38:45AM -0500, Douglas Tutty wrote:
> On Mon, Nov 20, 2006 at 09:52:26PM -0500, hendrik@topoi.pooq.com wrote:
> > On Mon, Nov 20, 2006 at 06:43:06PM -0500, Johan Kullstam wrote:
> >
> > >From what I hear, reiserfs and ext3 are both reasonably protected
> > against panic reboots -- the hard drives will have written or not
> > written the journal, and remounting the file system will figure out what
> > happened. What they have a hard time with is panic powerdowns --
> > because of the behaviour of some IDE drives -- apparently they report
> > data transfer complete when they have merely buffered it internally,
> > expecting it to be written real soon now. If the power fails before
> > this happens, the file system will assume data have been written which
> > in fact have not been written, and this could caouse journal failure.
> >
>
> > ext2, I'm told, has just enough extra redundancy that is is possible to
> > make a reasonable guess as th owhat's wrong by an fsck. rumour has it
> > that reiser, which stored data in a tree structure that's somewhat
> > independent of the file-system structure, is more vulnerable to problens
> > like confusing data with file-system structure.
> >
> > I don't know what the situatin is with JFS. Anybody know?
> >
>
> All I know is what I've experienced and what I have taken on faith:
>
> Reiserfs looses files on panic powerdowns (power failure) even if the
> filesystem structure survives. Reiserfsck doesn't fix this. This, for
> me, has been small files (unfortunaly, typically those in /etc) even
> though they weren't being written at the time of the power failure.
That sounds right.
>
> IBM says they designed JFS to allow a server to get back to work quickly
> after a power failure, which includes fixing problems so that it __can__
> work. I have enough experience with IBM to trust that when they design
> something to put their name on it (and use it in AIX) that it will do
> what they say it will do.
The hard part of this is, of course, to deal with disk drives that lie
about whether they have written.
I have respect for IBM too.
When a third-party developer decided to rely on IBM's specs for
OS/2's high-performance file system to write a disk
optimiser/defragmenter or some such, they build partitions with the
file system root in a valid-according-to-spec place that was
different from the place IBM had been putting it. OS/2 had
troubel reading these partitions. IBM fixed their HPFS
implementation so that it would work to spec.
A similar story with Microsoft: When an independently
written-to-spec utility failed to handle NTFS properly,
Bill Gates is reported to have said, "Looks kike they haven't
figured out all the intricacies of our file system yet."
>
> I tried to stress-test JFS by __moving__ directories from one drive to
> another and one partition to another and cutting the power in the
> middle. The move would only be partially complete but no files were
> lost; they either existed on one drive or the other, nothing got lost in
> limbo.
That sounds competent.
>
> Until I got my new Athlon system, I have always used old/slow hardware.
> Looking at the benchmark comparisions, reiserfs may be faster with small
> files because it embeds them in the directory structure but to do that
> it needs a lot more CPU overhead. So on my hardware, JFS has been
> faster than reiserfs.
>
> So I use JFS for everything.
>
> Doug.
I'm at the point of replacing one of my reiserfs's on an NFS server with
something else for reliability. (reliability is the *primary* criterion
for this server, by the way. I'd happily give up some speed for
reliability) I was going to go to ext3 because of its venerable age.
Now you hae me wondering about JFS.
DO you have any more relevant facts? or links to facts?
-- hendrik
Reply to: