>>>>> "mo" == Mertol Ozyoney <[EMAIL PROTECTED]> writes:

    mo> One of our customer is suffered from FS being corrupted after
    mo> an unattanded shutdonw due to power problem.

    mo> They want to switch to ZFS.

    mo> From what I read on, ZFS will most probably not be corrupted
    mo> from the same event.

It's not supposed to happen with UFS, either.  nor XFS, JFS, ext3,
reiserfs, FFS+softdep, plain FFS, mac-HFS+journal.  All filesystems in
popular use for many years except maybe NTFS are supposed to obey
fsync and survive kernel crashes and unplanned power outage that
happens after fsync returns, without losing any data written before
fsync was called.  The fact that they don't in practice is a warning
that ZFS might not, either, no matter what it promises in theory.

I think many cheap PeeCee RAID setups without batteries suffer from
``the RAID5 write hole'' which takes away all the guarantees of
no-power-fail-corruption that the filesystems made, and these broken
no-battery setups seem to be really popular.  If one used ZFS on top
of such a no-battery RAID instead of switching it to JBOD mode, ZFS
would be vulnerable, too.

One interesting part of ZFS's ``in theory'' pitch is that, if you use
redundancy with ZFS, the checksums may somewhat address this problem
described below:

 http://linuxmafia.com/faq/Filesystems/reiserfs.html

-----8<-----
You see, when you yank the power cord out of the wall, not all parts
of the computer stop functioning at the same time. As the voltage
starts dropping on the +5 and +12 volt rails, certain parts of the
system may last longer than other parts. For example, the DMA
controller, hard drive controller, and hard drive unit may continue
functioning for several hundred of milliseconds, long after the DIMMs,
which are very voltage sensitive, have gone crazy, and are returning
total random garbage. If this happens while the filesystem is writing
critical sections of the filesystem metadata, well, you get to visit
the fun Web pages at http://You.Lose.Hard/ .

I was actually told about this by an XFS engineer, who discovered this
about the hardware. Their solution was to add a power-fail interrupt
and bigger capacitors in the power supplies in SGI hardware; and, in
Irix, when the power-fail interrupt triggers, the first thing the OS
does is to run around frantically aborting I/O transfers to the
disk. Unfortunately, PC-class hardware doesn't have power-fail
interrupts. Remember, PC-class hardware is cr*p.
-----8<-----

I would suspect a ZFS mirror might have a better shot of coming
through that type of crazy power failure, but I don't know how
anything can be robust to a mysterious force that scribbles randomly
all over the disk.

On the downside there are some things I thought I understood about
SVM's ideas of quorum that I do not yet understand in the ZFS world.

also...FTR I use his ext3 rather than XFS myself, but I'm a little
skeptical of Ted Ts'o ranting above because he is defending a shortcut
he took writing his own filesystem.

And I'm not sure the cord-pulling problem he describes is really
universal, and is really a reason for XFS-users losing data that
ext3-users don't---it sounds like it could be a specific-quirk type
problem, a blip in history just like ``the 5-volt rail'' he talks
about (+5V?  what did they used to run on 5 volts, a disk motor or a
battery charger or something?).  The SGI engineers had the problem on
their specific hardware, and solved it, but it may or may not exist on
present machines.  Maybe current hardware has other equally weird
problems when one pulls the power cord.

-- 
READ CAREFULLY. By reading this fortune, you agree, on behalf of your employer,
to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED  agreements, licenses, terms-of-service, shrinkwrap, clickwrap,
browsewrap, confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its
partners, licensors, agents and assigns, in perpetuity, without prejudice to my
ongoing rights and privileges. You further represent that you have the
authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

Attachment: pgpQRPlS0ZITA.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to