What filesystem do you consider more appropriate for a (NFS)
server to use ? Suse (9.0, 64 bit version) includes several:

mkfs.cramfs http://sourceforge.net/projects/cramfs/
"apropos cramfs" and "man mkfs.cramfs" return nothing,
so I assume this one doesn't matter. (google found:
"cramfs is a Linux filesystem designed to be simple, small,
and to compress things well. It is used on a number of
embedded systems and small devices.")

mkfs.ext2
mkfs.ext3
Classical and journaled linux filesystems. dump(8) works
with both.

mkfs.jfs http://oss.software.ibm.com/jfs/
IBM's journaled file system. dump(8) is not available
for it.

mkfs.reiserfs
It is the default in SUSE and I use it in a number of
computers, but I don't trust it 100%* and it doesn't
have dump.

mkfs.xfs http://oss.sgi.com/projects/xfs/
SGI's XFS. This one does have xfsdump(8)
Is it reliable ? We used to have SGIs around here, but
that was quite a long time ago, so I don't remember if
they had XFS or something older.

I know I can make a script using find and cpio or tar to replace
dump, but I like dump (and specially restore -i).

I am most interested in reliability and not so much in performance
(ok, I don't want a slow filesystem either, but I suppose neither of
them is going to be actually slow, just not so fast as the others).

Can all of these filesystems use 64 bit file offsets (meaning
files bigger than 2GB) ?

Thanks in advance



* Some time ago I got some weird problem with reiserfs (or NFS,
since I was using it remotely). I didn't write down exactly what
happened but from my logs:

a script which included these lines:

ls -l *XXXX*
echo mv XXXX o.XXXX
mv XXXX o.XXXX
ls -l *XXXX*

gave this output:

-rw------- 1 root root 6728019145 Feb 7 22:44 o.XXXX
-rw------- 1 root root 6720225159 Feb 9 22:48 XXXX
mv XXXX o.XXXX
mv: cannot move `XXXX' to a subdirectory of itself, `o.XXXX'
-rw------- 1 root root 6720225159 Feb 9 22:48 o.XXXX

IIRC, I found that doing a ls on the directory didn't show one
of the files, but if one did an "ls XXXX" the file was there
(I don't remember if this happened locally, through NFS or in
both cases).

--
http://www.mat.uc.pt/~rps/

..pt is Portugal| `Whom the gods love die young'-Menander (342-292 BC)
Europe | Villeneuve 50-82, Toivonen 56-86, Senna 60-94

On 26 Feb 2004 18:32:58 -0000, Rui Pedro Mendes Salgueiro staggered into
the Black Sun and said:
Depends on the filesystem's intended use. If you're using lots and lots
of small files, ReiserFS is better. If you're using comparatively few
gigantic files, XFS would work better. If you're concerned about
backwards combatability, ext3 is better.

No.

Possible, but JFS is really not as popular as other filesystems, so it
may not be as well-supported.

Who needs dump? Linus himself officially discouraged its use. Use tar
or cpio or partimage or something.

Dunno about its reliability; I use ReiserFS and ext3 on my machines and
I've had zero problems with them. That's not quite true--thanks to a
bug in kernels 2.3.99..2.4.4 with VIA chipset DMA, my ReiserFS
partitions were partially scrozzled--but that would've happened to any
filesystem.

What, specifically, do you like about it? OK, interactive restore with
a shell-like interface. Hmm... maybe you'd like Amanda.

Yes. ext[23], JFS, and XFS have had this capability since the
beginning, the old ReiserFS 3.5 had a hard limit of 2G/file but the
current ReiserFS 3.6 has the limit at 2T and ReiserFS 4 will use even
larger offsets.

There were a few older kernels that showed strange problems when you
exported ReiserFS over NFS. I don't know precisely what the problem
was since I don't use NFS much, but I believe the problem has been fixed
for a year or so now.

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
http://www.brainbench.com / Hire me!
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rui Pedro Mendes Salgueiro <rps@rena.mat.uc.pt> wrote:
[..]

Haven't used that but I'm going to look into it, since it
supports online resizing.

I'd suggest considering in the following order:

1. ext3
2. ext3
3. ext3

The only thing missing from ext3, it can't be resized while
mounted, there are some patches, but I'm still waiting for
official support.

But then it's the most reliable FS I know of. For performance you
want decent SCSI disks in a heavily used fileserver, not some
cheapo IDE crap.

AFAIK yes, however tools like tar/etc need to have support for
that too, might require update/recompile.

Had some strange problems with reiserfs too, wouldn't suggest
using it on /.

Good luck

- --
Michael Heiming - RHCE (GPG-Key ID: 0xEDD27B94)

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of spam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAPkQ3AkPEju3Se5QRAh+7AKCplOrJLVCfG0oPvvo1CI 6hkYp2sACg0Deu
bDlgQrsEdfmBBvKASZpDT7w=
=HRz4
-----END PGP SIGNATURE-----

Thanks to you and Michael Heiming for your replies.

Some comments below:

Dances With Crows <danSPANceswitTRAPhcrows@usa.net> wrote:
Consider the following case: a user arrives here telling me that he
accidentally erased one file. The file is recent, so it is on last
night's tape (level 9 dump). With restore -i, I look for the file
(and I can recognise the name even if there is a minor typo) and
when I tell it to "extract" it reads the rest of the dump without
having to start from the beginning.

With tar or cpio, it would be a two pass process:
1 - tar tvf /dev/tape > list.of.files
2 - grep name list.of.files to find the exact name
3 - tar xvf /dev/tape full/name

Note that each pass is quite slow.

But this is not too bad. If the file is older and so it is on the level
0 backup (5 12GB tapes), it gets much worse. IIRC, the formats used
by tar or cpio have the file names interspersed with the files
contents, so to get a full listing it would mean to read the full
backup. Dump writes the file list at the beginning of the tape,
and at least in some versions, the rest of the list at the begiining
of each volume, so it is much faster to find it.

Writing this, I remembered the very old, pre-BSD version of dump
(System V Rel.3 or older). Yuck! There was no interactive restore,
(so two passes, one to find the exact name, one to extract it)
and IIRC individual restored files were renamed nnnn, in which nnnn
was the inode number.

In the past (some years ago) Suse 6.1 (?) was unable to use
files bigger than 2 GB. It was probably a limitation in the
kernel (size of off_t ?) and not in a specific filesystem,
since I was using NFS and the server did not have such a
limitation.

--
http://www.mat.uc.pt/~rps/

..pt is Portugal| `Whom the gods love die young'-Menander (342-292 BC)
Europe | Villeneuve 50-82, Toivonen 56-86, Senna 60-94

On Thu, 26 Feb 2004 20:08:40 +0100, Michael Heiming
<michael+USENET@www.heiming.de> wrote:

I've used it on several systems, and my home SUSE system is XFS
through and through - works well. Only thing that I watch out for is
compatability with rescue CDs such as LNX-BBC and Knoppix (why not?) -
except that both of those support XFS right from the start. But I
still can't shake the lure of compatability with ext3.

XFS supports the largest files of any of the major Linux filesystems
and is renowned for its massive capacities.

XFS, on the other hand, MUST be mounted to be resized....

From what I've seen, reliability exists across all of the filesystems.

I would recommend one of these:

1. LVM + ext3
2. LVM + XFS
3. LVM + ReiserFS
4. LVM + JFS (maybe)

LVM... LVM.... LVM.... LVM.... It hasn't come with Red Hat until
Advanced Server 3, and it didn't come with the Linux kernel until 2.6
from what I hear. But get it. If you use SGI's unified kernel patch
it'll include XFS with it.

So whatever you use, use LVM + a journaling filesystem. We won't even
mention SoftUpdates ;-)

David Douthitt (david@douthitt.net)
UNIX System Administrator
HP-UX, Unixware, Linux
Linux+, LPIC-1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Douthitt <ssrat@mailbag.com> wrote:
[..]

Sounds good.

[..]

Wouldn't use reiserfs, had too much bad experience with it.

AFAIK, LVM has been always made by sistina (www.sistina.com).

Sure I know LVM, I'd be interested why anyone would like to make
me using it. It's not that bad and perhaps suitable/needed for
some task, however LVM1 has some major shortcomings, it can't
resize a stripped FS while mounted. LVM2 can do this.

For some purposes I don't see the advantage, you just add more
complexity to the fs, while gaining nothing. Your millage may
be different.

What I'd really love to see, is a FS like AdvFS for Linux.

Perhaps ext3 one day gets those features.

BTW
Have you used GFS?

- --
Michael Heiming - RHCE (GPG-Key ID: 0xEDD27B94)

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of spam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAQ6AWAkPEju3Se5QRAqguAJ9caoxCZsu9qudpGs2Gum XoY8CFFgCfSyVy
d75jt9ciZXZqKI9hJ4ysV+o=
=ssI6
-----END PGP SIGNATURE-----

Rui Pedro Mendes Salgueiro wrote:

I would use either reiserfs (very fast and reliable) but problems when you
want to use ACLs or quota (personel experience). If you want to use quota
and/or ACLs I would use XFS. We use it since six months on 3 machines each
with 2TBytes of storage with a suse8.2 linux server. And its runs really
fine. Test have proven though, that reiserfs is a lot faster if you have to
handle lots of small files. Both can be extended online without unmounting.
One plus for XFS is the complete set of tools and documentation that come
with it.

I would not use ext3 if you care about performance and extensibility.

Rainer
--
---------------------------------------------------------------------------
Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022
Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312
Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke
Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html
---------------------------------------------------------------------------