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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox