linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Pittman <daniel@rimspace.net>
To: linux-raid@vger.kernel.org
Subject: Re: Fwd: Linux MD raid5 and reiser4... Any experience ?
Date: Sun, 08 Jan 2006 13:53:07 +1100	[thread overview]
Message-ID: <87ace7sa5o.fsf@rimspace.net> (raw)
In-Reply-To: 43BE3C99.4050706@ieee.org

Simon Valiquette <v.simon@ieee.org> writes:
> Francois Barre a écrit :
>> 2006/1/5, Daniel Pittman <daniel@rimspace.net>:
>>>Francois Barre <francois.barre@gmail.com> writes:

[...]

> AFAIK, ext3 volume cannot be bigger than 4TB on a 32 bits system.  I
> think it is important you know that in case it could be a concern for
> you.

Others have pointed out that this is not correct, so I don't repeat the
reasons there.

[...]

> On production server with large RAID array, I tends to like very much
> XFS and trust it more than ReiserFS (I had some bad experience with
> ReiserFS in the past).  You can also grow a XFS filesystem live, which
> is really nice.
>
> XFS is finally much faster than EXT3 and self-defragmenting, but that
> was not a concern for you anyway.

This is true.  I wouldn't recommend, personally, using XFS on a
production machine that didn't have a very reliable UPS associated.

XFS only journals meta-data, and writes that to disk quite frequently.
It, like most other filesystems, is much more relaxed about writing the
actual data to disk.

This is great from a hard restart situation -- it means no long fsck to
get the metadata consistent.

Unfortunately, the way that XFS is put together this means that any file
that you were actively writing it in the last minute or so before an
unclean restart has a good chance of having the metadata in journal, but
the data blocks unwritten.

That will have XFS replace the file content with ASCII NULL for you --
secure, but somewhat frustrating if you just lost critical system files
as a result.[1]


Assuming that you have otherwise reliable hardware, power problems are
the most common cause of unclean restarts.  The risks of XFS data loss,
in my experience, offset the performance benefits for most production
use.

ext3, for reference, can be asked to operate in the same mode as XFS
but, by default, does not do so.

Regards,
        Daniel

Footnotes: 
[1]  I may be somewhat bitter here, as I support a dozen machines that
     use XFS and are, sadly, not terribly reliable hardware.  As a
     result I spend far too much time pulling critical files back of
     backup tapes, and can look forward to that continuing until our
     migration away from that hardware is complete. :/
     


-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2006-01-08  2:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fd8d0180601050104x15079396h@mail.gmail.com>
2006-01-05  9:06 ` Fwd: Linux MD raid5 and reiser4... Any experience ? Francois Barre
2006-01-05 10:14   ` Daniel Pittman
2006-01-05 11:21     ` Francois Barre
2006-01-05 11:31       ` Gordon Henderson
2006-01-06  6:33       ` Daniel Pittman
2006-01-06  9:47       ` Simon Valiquette
2006-01-06 10:50         ` Francois Barre
2006-01-06 19:28           ` Forrest Taylor
2006-01-06 11:03         ` Kanotix crashed my raid PFC
2006-01-06 12:02           ` PFC
2006-01-06 12:08             ` PFC
2006-01-06 22:01               ` PFC
     [not found]                 ` <200601090803.03588.mlaks@verizon.net>
2006-01-09 18:30                   ` PFC
2006-01-06 19:05         ` Fwd: Linux MD raid5 and reiser4... Any experience ? Mike Hardy
2006-01-08  2:53         ` Daniel Pittman [this message]
2006-01-05 11:26     ` berk walker
2006-01-05 11:35       ` Francois Barre
2006-01-05 11:43         ` Gordon Henderson
2006-01-05 11:59         ` berk walker
2006-01-05 13:13         ` Bill Rugolsky Jr.
2006-01-05 13:38   ` John Stoffel
2006-01-05 14:03     ` Francois Barre
2006-01-05 18:55       ` John Stoffel
2006-01-06  9:08         ` Francois Barre
2006-01-06 10:49           ` Andre Majorel
2006-01-09  8:00             ` Molle Bestefich
2006-01-09  8:16               ` Gordon Henderson
2006-01-09  9:00                 ` Francois Barre
2006-01-09  9:24                   ` Molle Bestefich
2006-01-05 17:32 Andrew Burgess
2006-01-05 17:50 ` Francois Barre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ace7sa5o.fsf@rimspace.net \
    --to=daniel@rimspace.net \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).