Filesystem recommendations
in [Debian]
|
Prev: overcoming the 32k objects limit is ext3 - which file system to use?
Next: Why is Acroversion not properly updated?
From: Mark Allums on 25 Apr 2010 02:20 > On 04/24/2010 12:53 PM, B. Alexander wrote: >> Hi, >> So now, I would like to slowly start replacing my reiser3 partitions >> with...something else. There are two options, the old standards, e.g. >> ext3/4, xfs, etc, and then there are a slew of new filesystems, such as >> nilfs2, btrfs and exofs. You probably want ext3 now, and ext4 soon. Midterm, you will want ext4 and XFS. Longer term, btrfs will be the wasp's nipples, if it pans out. (Linus uses it now, allegededly.) I wanted to like ZFS, but Sun is now Oracle, and thus over it hangs a dark cloud. Besides, we can almost get the benefits of ZFS with Linux RAID plus LVM2. MAA (Why? ext3 and 4 are exceptionally well supported by Linux and GNU. XFS will be, too, probably.) -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD3DEEF.7050305(a)allums.com
From: Mike Castle on 25 Apr 2010 11:40 On Sat, Apr 24, 2010 at 10:53 AM, B. Alexander <storm16(a)gmail.com> wrote: > Does anyone have suggestions and practical experience with the pros and cons > of the various filesystems? Google is switching (has switched by now?) all of it's servers over to ext4. A web search will turn up more details on the subject. But they are mostly lots of big files. mrc -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/j2v537f90651004250829j1b0cb458y681b1732c2c2da4a(a)mail.gmail.com
From: Celejar on 25 Apr 2010 17:10 On Sat, 24 Apr 2010 19:46:51 -0700 Kevin Ross <kevin(a)familyross.net> wrote: .... > There's also JFS, which has been around for a number of years, and is > mature. It doesn't checksum your files, but it does use copy-on-write > (as do Btrfs and ZFS), which goes a long way to keeping your data from > getting corrupted, something XFS does not do. FWIW, there is apparently an ext3 COW project, but it seems a bit stagnant: http://www.ext3cow.com/Welcome.html Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100425170739.007f82ee.celejar(a)gmail.com
From: Stan Hoeppner on 26 Apr 2010 01:10 Ron Johnson put forth on 4/24/2010 2:11 PM: > On 04/24/2010 12:53 PM, B. Alexander wrote: >> Does anyone have suggestions and practical experience with the pros and >> cons of the various filesystems? >> > > XFS is the canonical fs for when you have lots of Big Files. I've also > seen simple benchmarks on this list showing that it's faster than > ext3/ext4. I've been very happy with XFS for all file sizes and counts, but my server isn't heavy duty by any means. It handles multiple 50-60MB mbox files with ease as well as serving Samaba shares containing 5000+ files per dir. Given that the large mbox files become fairly fragmented over time due to constant appends, having an online file defragmenter, xfs_fsr, is very handy. The myth that certain filesystems don't fragment files and thus don't need a defrag tool are just that, myths. I've run with mbox on both EXT2 and XFS, and the larger mbox files always fragment over time regardless of filesystem. Prior to my last xfs_fsr run, I had 10 mbox files (a single user) that ranged from 10-35 fragments each. Those in the 20-35 fragment range were 40-60MB files. I don't have empirical data to show how much this negatively affected performance, but my mail client did seem a bit snappier after defragging. > nilfs2, btrfs and exofs are *definitely* still beta or even alpha. I've not played with any of these myself, but what I'm seeing on the various mailing lists suggests what Ron states here. > xfs and ext[34] can all be extended. For production servers with a > working UPS, I'd go with ext3 for / & /boot and xfs (since it hates > sudden power outages) for the "/data" directories. For production > workstations, I'd stick with the standby ext3 for / & /boot and ext3 or > xfs for /home and "/data" (depending on the workload). For production servers I'd go with XFS everywhere as long as your kernel (and rescue disk kernel) has XFS built-in. Reliable power (via UPS and/or generator) is part of the definition of "production" server, so there's no reason to shy away from XFS for any partitions or logical volumes due to power loss fears. Some recent FS benchy comparisons with 2.6.34-rc3 on a big RAID setup: http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-rc3/2.6.34-rc3.html As always, no single fs wins across the board. XFS falls flat on its face in the synthetic mail server test, but does very well in all others. Given its results in the mail test are almost identical to EXT4, and that EXT4 no-barrier increases performance 7 fold, I'd say some tweaking of XFS would bring its performance back in line with the others. -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD51EF5.7040201(a)hardwarefreak.com
From: Stan Hoeppner on 26 Apr 2010 01:50
Ron Johnson put forth on 4/24/2010 5:48 PM: >> Define "hates sudden power outages"...Is it recoverable? >> > > They got pretty corrupted. Maybe it's been robustified in the > intervening years. Drop this in the "lore" category. Any machine using pretty much any modern filesystem can suffer corruption with a given set of heavy write circumstances and depending on the applications. Some FS do better than others, but all will suffer corruption under the right mix of circumstances. XFS got a bad rap long ago for a couple of fairly high profile corruptions. But, given SGIs customers, nearly all are going to be "high profile" as all the systems would be huge and storing important data. The bulk of SGI's customers are traditionally U.S. government labs, oil & gas exploration companies, movie studios, pharmaceutical labs, NASA, etc. One really bad incident can carry a stigma for a long time, deservedly or not. You may find this an interesting read: http://www.flamingspork.com/talks/2007/06/eat_my_data.odp -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD527EE.2010907(a)hardwarefreak.com |