[SATLUG] Filesystem/RAID advice

travis+ml-satlug at subspacefield.org travis+ml-satlug at subspacefield.org
Wed Dec 1 20:54:14 CST 2010


On Sun, Oct 24, 2010 at 11:08:09PM -0500, Brad Knowles wrote:
> For the Infrant ReadyNAS system, these statements are not applicable.

Cool.  Next time I'm looking for storage, I might check those out.

> UPS also doesn't do you a damn bit of good when the problem is that
  your admin (or your spouse) fat-fingers something and your data goes
  P00F!

Of course not.  And RAID just makes the deletes (or corruption) more
efficient, affecting both copies at once :-)

> And since Hans Reiser was convicted of murdering his wife, I got the impression that the whole thing kind of just shriveled up and died.

Nah, ReiserFS lives on, they put out a new version, but yeah, it seems
to have lost momentum.  ext4 is a stopgap, BTRFS is the heir apparent.

> XFS is something I came to have a great deal of trust in, at least
  the fully-baked version on SGI Irix.  I never got the feeling that
  XFS on Linux had ever gotten anywhere remotely close to that same
  level of robustness and reliability.

I heard XFS performed better for large files, and I tried it on Linux
many years ago.  I was using SELinux and LVM at the time, on FC5 or
something like that.  I found that, more often than not, during
shutdown, the kernel would panic in some function involving xfs and
timestamps.  This meant that shutting down was usually an unclean
event.

My experience has been that integrity is more important to me than
performance.  I ran from XFS, quickly, and never looked back.  YMMV.

Example of a lesson I never want to experience again:
http://www.subspacefield.org/security/hard_drives_of_doom/

Unfortunately, reliability of this kind is hard to get metrics on.
I end up just trying it for a while and seeing how it works, and
keeping good backups. (RAID is not a backup)

For that, I'm working on this project:
http://www.subspacefield.org/security/hdb/

ZFS has some very cool stuff, I hope we get something like it well
integrated with Linux one day.

One thing about oddball file systems; if you ever have to recover the
data, not having the tools on your ISOs can make your life hard.  You
can work around this by doing a full Linux install on a USB stick,
then installing your tools.  Slow but works.

BTW, an interesting thing about integrity...

You can think of it as a stack, like the OSI model, where you write
your data in an application, and it goes down through the kernel
buffer cache, device driver, HDC, out the bus, through hard drive
microcode, stored on disk.  Then when you read it, it comes back up
through much the same path.  You can have all the integrity in your
drive array you want, but if the kernel hoses your data, it's stored
hosed, and it comes back corrupt.  What you really want is end-to-end
integrity protection, or at least detection of corruption.  So
ideally, the application would be doing it, so it's protected all the
way down and up the stack.  I hear Oracle might be able to do
something like this.

And if you want to worry about hardware errors, you've got the chance
for errors while it's stored in RAM.  IIRC, 4GB of non-ECC RAM would
have a one bit error every day.  Even if you have ECC RAM and have it
enabled in all the right places, the system bus probably does not have
it on PCs.

It's analogous in my mind to link-level encryption versus end-to-end
encryption.
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://www.satlug.org/pipermail/satlug/attachments/20101201/d6fd0245/attachment-0001.bin


More information about the SATLUG mailing list