From: Steve Costaras <stevecs@chaven.com>
To: xfs@oss.sgi.com
Subject: Re: Best filesystems ?
Date: Sat, 23 Oct 2010 19:17:49 -0500 [thread overview]
Message-ID: <4CC37B2D.3050005@chaven.com> (raw)
In-Reply-To: <19651.9652.631329.903552@tree.ty.sabi.co.uk>
On 2010-10-23 13:13, Peter Grandi wrote:
>
> * JFS is good for almost everything, including largish filesystems
> on somewhat largish systems with lots of processes accessing
> lots of files, and works equally well on 32b and 64b, is very
> stable, and has a couple of nice features. Its major downside is
> less care than XFS for barriers. I think that it can support
> well filesystems up to 10-15TB, and perhaps beyond. It should
> have been made the default for Linux for at least a decade
> instead of 'ext3'.
Would comment here that JFS is indeed very good, but does have a problem
when reaching/hitting the 32TB boundary. This appears to be a user
space tool issue. It is the main reason why I switched over to XFS as
was running into this problem too often.
> * XFS is like JFS, and with somewhat higher scalability both as to
> sizes and as to higher internal parallelism in the of multiple
> processes accessing the same file, and has a couple of nice
> features (mostly barrier support, but also small blocks and large
> inodes). Its major limitation are internal complexity and should
> only be used on 64b systems. It can support single filesystems
> larger than 10-15TB, but that's stretching things.
Have used XFS up to 120TB myself on real media (i.e. not sparse files)
under linux; will be building >128 shortly. Have used more w/ XFS
Irix in the past.
Generally I find with most file systems/tools there are many bugs when
you cross bit boundaries where they were not tested. Whenever
using/planning large systems /always/ test first and have good backups.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-10-24 0:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 23:04 avoid mbox file fragmentation Stan Hoeppner
2010-10-19 23:42 ` Dave Chinner
2010-10-20 2:36 ` Stan Hoeppner
2010-10-20 11:31 ` Peter Grandi
2010-10-20 3:03 ` Stan Hoeppner
2010-10-21 1:55 ` Dave Chinner
2010-10-20 11:50 ` Peter Grandi
2010-10-21 2:00 ` Dave Chinner
2010-10-21 16:39 ` Peter Grandi
2010-10-21 20:06 ` Best filesystems ? Andrew Daviel
2010-10-22 2:47 ` Stan Hoeppner
2010-10-23 18:13 ` Peter Grandi
2010-10-23 20:16 ` Emmanuel Florac
2010-10-26 0:55 ` hank peng
2010-10-26 7:19 ` Emmanuel Florac
2010-10-23 21:28 ` Stan Hoeppner
2010-10-24 0:17 ` Steve Costaras [this message]
2010-10-24 18:27 ` Michael Monnerie
2010-10-24 20:52 ` Emmanuel Florac
2010-10-20 11:21 ` avoid mbox file fragmentation Peter Grandi
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=4CC37B2D.3050005@chaven.com \
--to=stevecs@chaven.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.