Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

On the State of Linux File Systems

kdawson posted more than 5 years ago | from the here-hold-this-for-me dept.

Data Storage 319

kev009 writes to recommend his editorial overview of the past, present and future of Linux file systems: ext2, ext3, ReiserFS, XFS, JFS, Reiser4, ext4, Btrfs, and Tux3. "In hindsight it seems somewhat tragic that JFS or even XFS didn't gain the traction that ext3 did to pull us through the 'classic' era, but ext3 has proven very reliable and has received consistent care and feeding to keep it performing decently. ... With ext4 coming out in kernel 2.6.28, we should have a nice holdover until Btrfs or Tux3 begin to stabilize. The Btrfs developers have been working on a development sprint and it is likely that the code will be merged into Linus's kernel within the next cycle or two."

cancel ×

319 comments

Sorry! There are no comments related to the filter you selected.

The article is incorrect with respect to ext4... (5, Informative)

tytso (63275) | more than 5 years ago | (#25927531)

The article states that ext4 was a Bull project; and that is not correct.

The Bull developers are one of the companies involved with the ext4 development, but certainly by no means were they the primary contributers. A number of the key ext4 advancements, especially the extents work, was pioneered by the Clusterfs folks, who used it in production for their Lustre filesystem (Lustre is a cluster filesystem that used ext3 with enhancements which they supported commercially as an open source product); a number of their enhancements went on to become adopted as part of ext4. I was the e2fsprogs maintainer, and especially in the last year, as the most experienced upstream kernel developer have been responsible for patch quality assurance and pushing the patches upstream. Eric Sandeen from Red Hat did a lot of work making sure everything was put together well for a distribution to use (there are lots of miscellaneous pieces for full filesystem support by a distribution, such as grub support, etc.). Mingming Cao form IBM did a lot of coordination work, and was responsible for putting together some of the OLS ext4 papers. Kawai-san from Hitachi supplied a number of critical patches to make sure we handled disk errors robuestly; some folks from Fujitsu have been working on the online defragmentation support. Aneesh Kumar from IBM wrote the 128->256 inode migration code, as well as doing a lot of the fixups on the delayed allocation code in the kernel. Val Henson from Red Hat has been working on the 64-bit support for e2fsprogs in the kernel. So there were a lot of people, from a lot of different companies, all helping out. And that is one of the huge strengths of ext4; that we have a large developer base, from many different companies. I believe that this wide base of developer is support is one of the reasons why ext3 was more succesful, than say, JFS or XFS, which had a much smaller base of developers, that were primarily from a single employer.

MOD PARENT INFORMATIVE (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#25927611)

Very insightful. Just goes to show the power of open source.

Re:The article is incorrect with respect to ext4.. (5, Informative)

tytso (63275) | more than 5 years ago | (#25927637)

Oh, by the way... forgot to mention. If you are looking for benchmarks, there are some very good ones done by Steven Pratt, who does this sort of thing for a living at IBM. They were intended to be in support of the btrfs filesystem, which is why the URL is http://btrfs.boxacle.net/ [boxacle.net] . The benchmarks were done in a scrupulously fair way; the exact hardware and software configurations used are given, and multiple workloads are described, and the filesystems are measured multiple times against multiple workloads. One interesting thing from these benchmarks is that sometimes one filesystem will do better at one workload and at one setting, but then be disastrously worse at another workload and/or configuration. This is why if you want to do a fair comparison of filesystems, it is very difficult in the extreme to really do things right. You have to do multiple benchmarks, multiple workloads, multiple hardware configurations, because if you only pick one filesystem benchmark result, you can almost always make your filesystem come out the winner. As a result, many benchmarking attempts are very misleading, because they are often done by a filesystem developer who consciously or unconsciously, wants their filesystem to come out on top, and there are many ways of manipulating the choice of benchmark or benchmark configuration in order to make sure this happens.

As it happens, Steven's day job as a performance and tuning expert is to do this sort of benchmarking, but he is not a filesystem developer himself. And it should also be noted that although some of the BTRFS numbers shown in his benchmarks are not very good, btrfs is a filesystem under development, which hasn't been tuned yet. There's a reason why I try to stress the fact that it takes a long time and a lot of hard work to make a reliable, high performance filesystem. Support from a good performance/benchmarking team really helps.

Re:The article is incorrect with respect to ext4.. (1)

sjames (1099) | more than 5 years ago | (#25928193)

As a result, many benchmarking attempts are very misleading, because they are often done by a filesystem developer who consciously or unconsciously, wants their filesystem to come out on top, and there are many ways of manipulating the choice of benchmark or benchmark configuration in order to make sure this happens.

The other side of the coin can come up as well. If you develop and test everything on one platform with one test workload, it's easy to unintentionally make it highly optimal for that exact setup and terrible elsewhere.

Re:The article is incorrect with respect to ext4.. (2, Interesting)

grimJester (890090) | more than 5 years ago | (#25928329)

As a result, many benchmarking attempts are very misleading, because they are often done by a filesystem developer who consciously or unconsciously, wants their filesystem to come out on top, and there are many ways of manipulating the choice of benchmark or benchmark configuration in order to make sure this happens.

Wouldn't it be logical to assume a filesystem developer has an idea on what the workload and hardware will be like _before_ writing his filesystem, then picking a benchmark that suits his ideas on what a filesystem is supposed to do? No manipulation necessary, intentional or otherwise.

Re:The article is incorrect with respect to ext4.. (2, Insightful)

transami (202700) | more than 5 years ago | (#25928343)

Repeato ad absurdium...

All these fancy features, but we are still using filename extensions (eg. .zip) to specify data types.

Did OOP even happen?

Re:The article is incorrect with respect to ext4.. (2, Insightful)

dougisfunny (1200171) | more than 5 years ago | (#25928505)

What do you want to specify the data type?

Some non-human readable meta data? If someone sends you a Not-a-virus.txt in an email attachment, what kind of file is it? An executable a funny story? How would you know?

Re:The article is incorrect with respect to ext4.. (1)

SmackedFly (957005) | more than 5 years ago | (#25928615)

Because the operating system would tell you what the metadata means. I don't quite see how 'file.notavirus' and 'file' with metadata saying 'notavirus' makes any difference apart from the latter being more flexible. Still. nothing prevents us from doing both, and as it stands it's too hard to establish cross-operating system support for it to be feasible.

Re:The article is incorrect with respect to ext4.. (0, Insightful)

Anonymous Coward | more than 5 years ago | (#25928519)

Seconded.

The one most wanted feature is the ability to store the mime type (or something like that) of a file.

With all the search features in modern OSes, even the file name should take second place to that.

Re:The article is incorrect with respect to ext4.. (1)

Kent Recal (714863) | more than 5 years ago | (#25928557)

Oh, who does that?
My OS certainly doesn't care.

magic (0)

Anonymous Coward | more than 5 years ago | (#25928605)

NAME file - determine file type SYNOPSIS file [-bchikLnNprsvz] [--mime-type] [--mime-encoding] [-f namefile] [-F separator] [-m magicfiles] file file -C [-m magicfile] file [--help] DESCRIPTION This manual page documents version 4.24 of the file command. file tests each argument in an attempt to classify it. There are three sets of tests, performed in this order: filesystem tests, magic tests, and language tests. The first test that succeeds causes the file type to be printed. The type printed will usually contain one of the words text (the file contains only printing characters and a few common control characters and is probably safe to read on an ASCII terminal), executable (the file conâ tains the result of compiling a program in a form understandable to some UNIX kernel or another), or data meaning anything else (data is usually âbinaryâ(TM) or non-printable). Exceptions are well-known file formats (core files, tar archives) that are known to contain binary data. When adding local definitions to /etc/magic, make sure to preserve these keywords. Users depend on knowing that all the readable files in a directory have the word âoetextâ printed. Donâ(TM)t do as Berkeley did and change âoeshell commands textâ to âoeshell scriptâ. The filesystem tests are based on examining the return from a stat(2) system call. The program checks to see if the file is empty, or if itâ(TM)s some sort of special file. Any known file types appropriate to the sysâ tem you are running on (sockets, symbolic links, or named pipes (FIFOs) on those systems that implement them) are intuited if they are defined in the system header file . The magic tests are used to check for files with data in particular fixed formats. The canonical example of this is a binary executable (compiled program) a.out file, whose format is defined in , and possibly in the standard include directory. These files have a âmagic numberâ(TM) stored in a particular place near the beginning of the file that tells the UNIX operating system that the file is a binary exeâ cutable, and which of several types thereof. The concept of a âmagicâ(TM) has been applied by extension to data files. Any file with some invariâ ant identifier at a small fixed offset into the file can usually be described in this way. The information identifying these files is read from /etc/magic and the the compiled magic file /usr/share/file/magic.mgc, or the files in the directory /usr/share/file/magic if the compiled file does not exist. In addition, if $HOME/.magic.mgc or $HOME/.magic exists, it will be used in preference to the system magic files.

Re:The article is incorrect with respect to ext4.. (1)

siride (974284) | more than 5 years ago | (#25928693)

There are extended attributes and magic numbers. Some file managers seem to make limited use of these. I guess the problem with extended attributes is that they aren't guaranteed to be transferable along with the file when you, e.g., upload the file to a website, or transfer it to another computer. Only the main stream of a file is guaranteed to be transfered.

But make no mistake, the filesystem fully supports this kind of information. We just don't seem to make much use of it right now.

what fs out there... (0)

Anonymous Coward | more than 5 years ago | (#25927541)

...can I configure to use large extents (like in the megabytes range)?

Re:what fs out there... (5, Informative)

tytso (63275) | more than 5 years ago | (#25927573)

Ext4 supports up to 128 megabytes per extent, assuming you are using a 4k blocksize. On architectures where you can use a 16k page size, ext4 would be able to support 2^15 * 16k == 512 megs per extent. Given that you can store 341 extent descriptors in a 4k block, and 1,365 extent descriptors in a 16k block, this is plenty...

Re:what fs out there... (2, Interesting)

Bandman (86149) | more than 5 years ago | (#25927797)

You seem very knowledgeable regarding filesystems in general. I'm interested in learning more about filesystems and how they work. To give you an idea of where I am, I believe I know what blocksize is, but I don't know what an extent is, and how it relates to performance (or why the grandparent would like extents several megabytes large).

What resources would you suggest to people who are looking to learn more?

Re:what fs out there... (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#25927877)

wikipedia is always a good starting point. As is Google.

Re:what fs out there... (5, Funny)

Knuckles (8964) | more than 5 years ago | (#25927953)

You seem very knowledgeable regarding filesystems in general.

Dude, it should have been a hint when tytso [wikipedia.org] wrote,

I was the e2fsprogs maintainer, and especially in the last year, as the most experienced upstream kernel developer have been responsible for patch quality assurance and pushing the patches upstream.

Re:what fs out there... (4, Funny)

Kent Recal (714863) | more than 5 years ago | (#25928689)

Ah, anyone can edit wikipedia. I say he's just showing off to get the chicks!

Lightweight (4, Insightful)

postbigbang (761081) | more than 5 years ago | (#25927551)

A cute FA in some ways, but bereft of content. Wish there was something to see here, like comparisons regarding integrity, access costs, evolution from JFS and Andrews journaled FS, etc. No real meat (with apologies to the vegetarians out there). Just a lightweight historical analysis with some glib suggestions of current adaptations.

Re:Lightweight (5, Funny)

Anonymous Coward | more than 5 years ago | (#25927893)

Appologies accepted.

Anonymous Cow

ZFS!! (3, Interesting)

Anonymous Coward | more than 5 years ago | (#25927639)

What Sun needs to do is release ZFS under a proper license so we can finally have 1 unified filesystem. Yes, we can use it under FUSE, but this brings unnecessary overhead and problems. It will be nice when we can transport disks around, similar to fat(32), and not have to worry about whether another OS will be able to read it or not. On top of that, CRC block checksumming, high performance, smb/nfs/iscsi support integrated, Volume AND partition manager.

Come on Sun! Are you listening??

Re:ZFS!! (5, Funny)

TheRaven64 (641858) | more than 5 years ago | (#25927709)

Sun has released it under a proper license and we can finally have 1 unified filesystem. The 'we' in this case being Solaris, Mac OS X, and FreeBSD users, of course.

Alllrig.... Oh. (5, Funny)

Gazzonyx (982402) | more than 5 years ago | (#25927959)

Never have I been so happy and so angry in such a short period of time. I salute you, yet still shake my fist angrily in your general direction.

Re:ZFS!! (0, Interesting)

Anonymous Coward | more than 5 years ago | (#25927965)

Malicious licensing at its best; help anyone with a corporate interest, hurt anyone with a Free Software interest. Sun pulled off the perfect fuck you to the existing Free Software community when it released ZFS and DTrace.

They didn't even do that to Java's licensing, which while not being technically as advanced and unique as the above mentioned software, is probably worth a whole hell of a lot more.

Re:ZFS!! (0)

Anonymous Coward | more than 5 years ago | (#25928887)

So, tell me. Just where did the OSS movement develop this childish demand that it be given everything? It's really impudent; probably why a lot of companies ignore various aspects of the GPL.

Re:ZFS!! (2, Insightful)

Anonymous Coward | more than 5 years ago | (#25927743)

Shouldn't ext2 already be that unified file system? Oh, that's right -- GPL prevents anybody else from using. Just like GPL prevents ZFS code from being used in Linux. Looks like the problem is the GPL.

Re:ZFS!! (4, Insightful)

harry666t (1062422) | more than 5 years ago | (#25927907)

You can have an alternative implementation of ext2 that wouldn't have to use GPL'd code from Linux. I saw ext2/3 drivers for Windows and I'm pretty sure that at least some of the non-GPL OSs out there (Mac? BSDs? Solaris?) can read/write ext2.

However, you can't reimplement ZFS under any other license (CDDL is licensing some of the patents that cover the ZFS only to the users of the original implementation or its derivatives). I'd say it's *BOTH* GPL's and CDDL's fault (what's more, Sun chose CDDL exactly because it's GPL-incompatible).

Re:ZFS!! (1)

Directrix1 (157787) | more than 5 years ago | (#25928589)

The fact that I can't use Sun's software how I want is a problem with GPL how?

Re:ZFS!! (3, Insightful)

beelsebob (529313) | more than 5 years ago | (#25928837)

Because Sun are licensing the software for you under a free and open source software license. The only thing stopping you from using it is that it's a license that doesn't agree with the ideology of the "all FOSS must be viral" GPL guys, and thus can't be used with GPLed software. There's plenty of non-GPLed projects that are happily getting on and using ZFS, but GPL guys can't. I'd say that makes it pretty obvious what the problem is.

Re:ZFS!! (1)

rubycodez (864176) | more than 5 years ago | (#25929145)

yes, problem is Sun's stupid licensing once again preventing them from gaining wide adoption or turning a profit with software (see also Java). Sun is losing money, too little too late in the direction of open source. bye bye Sun.

Re:ZFS!! (4, Interesting)

dokebi (624663) | more than 5 years ago | (#25927991)

UFS (of BSDs) is under the most liberal license possible, yet it's definitely not the most widely used. FAT32 is patented by MS, and it is the most widely used. So, do you still think the problem is GPL?

Re:ZFS!! (5, Insightful)

diegocgteleline.es (653730) | more than 5 years ago | (#25927947)

ZFS has redefined the way future filesystems are going to be designed. But there is no way that it's going to be the "last" filesystem.

As shocking as it may seem to those who have drunk the marketing kool aid, we'll see more filesystems. Filesystem research is as alive as it always was. They'll try to copy the good ideas of ZFS and they will try to avoid the disadvantages (which every software has). So you are never going to have "1 unified filesystem". It's never going to happen. And it's a good thing.

Re:ZFS!! (1, Redundant)

isorox (205688) | more than 5 years ago | (#25928259)

They'll try to copy the good ideas of ZFS and they will try to avoid the disadvantages (which every software has). So you are never going to have "1 unified filesystem". It's never going to happen. And it's a good thing.

One thing I'd really like is using free space on a raidz(2) as a spare disk.

Imagine the following
10 1TB disks in a raid5/raidz, giving 9TB of space. You are currently using 7TB, this peaks to 8.5TB at the weekend while backups are staged (or whatever).

During the week you have unused space. The file system detects this, and in the background transparently makes a second parity drive out of the spare space, effectively changing to raid6/z2 on the fly.

If you suddenly need to write another 1.5TB, the fake parity is discarded. When your free space drops back below 8TB, the second parity drive is recreated.

If you lose one of your disks with a raid5/z, you in a danger zone until you replace it, and it rebuilds. This way, you are only in a danger zone if you lose the disk at the weekend when you need the extra space -- you can afford to lose another one (your effective free space keeps reducing).

When you put a new drive in, assuming you have the free space originally, there's no rebuild time (your parity already exists).

Another feature would be automatically copying of frequently accessed files -- if a certain bunch of files on a website becomes popular, they would be transparently copied across the spindles to increase access time.

Finally extend the idea of ZFS to a multi-machine cluster, zfs meets lustre.

Re:ZFS!! (1)

Unknown Relic (544714) | more than 5 years ago | (#25928623)

Another feature would be automatically copying of frequently accessed files -- if a certain bunch of files on a website becomes popular, they would be transparently copied across the spindles to increase access time.

Doesn't Sun's new ZFS-based "open storage" hardware do this already to some extent? It automatically moves the most accessed files onto the solid state drives to speed things up.

Re:ZFS!! (5, Interesting)

Kent Recal (714863) | more than 5 years ago | (#25928641)

I hear you and I'm sure the filesystem developers have the same ideas in their heads.
The problem is that there are some really hard problems involved with these things.

In the end everybody wants basically the same thing: A volume that we can write files to.
This volume should live on a pool of physical disks to which we can add and remove disks at will and during runtime.

The unused space should always be used for redundancy, so when our volume is 50% full then we'd expect that 50% of the disks (no matter which) can safely fail at any time without data loss.

Furthermore we don't really want to care about any of these things. We just want to push physical disks into our server, or pull them, and the pool should grow/shrink automagically.
And ofcourse we want to always be able to split a pool into more volumes, as long as there's free space in the pool we're splitting from. Ideally without losing redundancy in the process.

We want all these things and on top we want maximum IOPS and maximum linear read/write performance in any situation. Oh, and we won't really be happy until a pool can span multiple physical machines (that will auto re-sync after a network split and work-as-expected over really slow and unrealiable networks), too.

ZFS is a huge step forward in many of these regards and there's a whole industry built solely around these problems.
Only time will tell which of these goals (and the ones that I omitted here) can really be achieved and how many of them can be addressed in a single filesystem.

Re:ZFS!! (1, Insightful)

jopsen (885607) | more than 5 years ago | (#25927995)

It will be nice when we can transport disks around, similar to fat(32), and not have to worry about whether another OS will be able to read it or not.

I'm no filesystem expert... But I think different filesystems for different purposes is a good idea... Do you want to use ZFS on a flash disk or external harddrive... (the ladder might make a little sense).

Generally I don't get all the fuss about ZFS... Okay, it's cool that we'll need more energy to reach it's limits than needed to boil this oceans...

smb/nfs/iscsi support integrated, Volume AND partition manager.

Yes, that's cool... But why does it need to be *in* the filesystem???
I'm not expert but AFAIK we've got LVM for volume management, and we can run any filesystem ontop of LVM... I think the idea of having volume management separate from filesystem sounds like a good idea, as it would enable you to used different filesystems for different purposes...
But hey maybe I'm missing something, why not improve or create a replacement for LVM instead of including volume management in the filesystem?

Re:ZFS!! (4, Interesting)

atrus (73476) | more than 5 years ago | (#25928141)

Because having a block based filesystem that has no notion of what the underlying storage is "dumb". ZFS fixes those problems.

Want to create a new filesystem in ZFS? Sure, no problem. You don't even need to specify a size, it will use whatever space the storage pool has available, no pre-allocation needed. How about removing one? Ok, its removed. Yes, it only took a second to do that. A traditional LVM + FS system can't do that - you need to resize, move, and tweak filesystems when doing any of the above operations - time consuming and limited.

And if you're asking why you'd want to create and remove filesystems on the fly, there is one word for that: snapshots. Its quite feasible to generate snapshots many times per day for a ZFS backed fileserver (or even database server). Someone created a file at 9am and then accidentally nuked it before lunch? Don't worry, its still present in the 10am and 11am snapshots. All online, instantly available.

Re:ZFS!! (4, Interesting)

ArbitraryConstant (763964) | more than 5 years ago | (#25928233)

> But hey maybe I'm missing something, why not improve or create a replacement for LVM instead of including volume management in the filesystem?

Maybe. But it would be a lot harder.

Think about LVM snapshots for example. LVM allocates a chunk of the disk for your filesystem, and then a chunk of disk for your snapshot. When something changes in the parent filesystem, the original contents of that block are first copied to the snapshot. But if you've got two snapshots, it has to be copied to two places, and each snapshot needs its own space to store the original data. Because ZFS/BTRFS/etc are unified, they can keep the original data for any number of snapshots by the simple expedient of leaving it alone and writing the new data someplace new.

LVMs can grow/shrink filesystems, but filesystems deal with this somewhat grudgingly. LVM lacks a way to handle dynamic allocation of blocks to filesystems in such a way that they can give them back dynamically when they're not using them. ZFS/BTRFS/etc can do this completely on the fly. LVMs rely on an underlying RAID layer to handle data integrity, but most RAID doesn't do this very well. BTRFS is getting a feature that allows it to handle seeky metadata differently than data (eg, use an SSD as a fast index into slow but large disks).

It is conceivable that an advanced volume manager could be created that does all these things and all the rest (eg checksumming) just as well... but I think the key point is that this isn't something you can do without a *much* richer API for filesystems talking to block devices. They'd need to be able to free up blocks they don't need anymore, and have a way to handle fragmentation when both the filesystem and the volume manager would try to allocate blocks efficiently. They'd need substantially improved RAID implementations, or they'd need to bring the checksumming into the volume manager. I'm not saying it can't be done, but doing it as well as ZFS/BTRFS/etc when you're trying to preserve layering would be very tough. At a minimum you'd need new or substantially updated filesystems and a new volume manager of comparable complexity to ZFS/BTRFS/etc. I understand the preference for a layered approach, but I just don't think it's competitive here.

Re:ZFS!! (2, Informative)

SanityInAnarchy (655584) | more than 5 years ago | (#25928785)

You just have to draw the layers differently.

I've repeatedly proposed something, only to find that ZFS already implements it: Define one layer which is solely responsible for storing your bare primitives, like a sequence of data. It is the FS-level equivalent of malloc/free.

Then, implement everything else on top of that layer. Databases could sit directly on the layer -- no reason they need to pretend to create files. Filesystems would sit on that layer, implementing structures like directories and POSIX file permissions.

Of course, while I'm at it, I have this other idea -- unify disk caches. It should be possible for me to allocate my entire available free space as a shared cache, between my package manager, browser, everything -- then, provide a common mechanism for reclaiming that space when something wants disk space.

Re:ZFS!! (0)

Anonymous Coward | more than 5 years ago | (#25928165)

The licensing is only an excuse to put the blame on Sun. Linus would never allow it in the kernel because it breaks the filesystem layering. This was the same reason ReiserFS was never allowed into the kernel, despite being superior to the alternatives at the time.

What I never understood was why Linux didn't adopt BSD's UFS2 (soft updates). I switched my development machine from Linux to FreeBSD and saw massive performance gains when compiling (it went from being disk bound to CPU bound). This was despite efforts to migrate from ext3 to a tuned XFS and putting everyone on 10k raptor drives / 4 core Xeons. In the end they spent an enourmous amount of effort trying to tune Linux - and failing - and are now putting a similar amount trying to rewrite the build system. And while they spend all this effort, time, and money trying to get a decent environment I'm just doing great on UFS2...

Re:ZFS!! (1)

Jesus_666 (702802) | more than 5 years ago | (#25928535)

Actually, if you want a filesystem usable by everyone it will definitely have to come from Microsoft. MS is not going to adopt someone else's FS unless they really have to, so the only serious contenders are FAT32, NTFS and exFAT (things like UDF are highly unlikely as Microsoft probably won't support it for anything but DVD images).

FAT32 is the current portability king. However, it's also old and extremely limited and people stopped liking it half a decade ago.

NTFS works... kinda. For example, you can mount a Vista NTFS disk unter XP but you're going to lose some metadata. XP NTFS is supported on every computer equipped with FUSE and ntfs-3g and on every computer running a new-ish Windows. Everywhere else it's useless and ntfs-3g is hardly a default package in most distros so no dice.

exFAT is essentially FAT64. It supports large files and has some improvements but in general it's very much FAT32's successor, being lightweight and relatively uncomplicated. While this sounds ideal for a widely supported filesystem there are no free exFAT implementations yet and people aren't sure whether Microsoft is going to allow the existence of one. So this one's not a winner, either.


Everything else will remain *nix-only so, yes, FAT32 is still the only option if you want complete portability (UDF if you can live with jumping through hoops). And it's going to stay that way for the forseeable future.

Re:ZFS!! (2)

SanityInAnarchy (655584) | more than 5 years ago | (#25928817)

Actually, if you want a filesystem usable by everyone it will definitely have to come from Microsoft.

It doesn't much matter whether they cooperate. Even if they insist that the Windows boot device continue to be NTFS, there's a standard way to write filesystem drivers for Windows (ext2 is already supported), and it's easy to put just about everything except Windows itself on another partition, if we have to. (Which we probably won't -- we could even slipstream it in.)

So, we can force the issue.

And suppose I have a portable hard drive, which I want to make sure is readable everywhere -- all I have to do is make a separate FAT32 partition with all the relevant software on it for Windows and OS X to read the other partition.

ntfs-3g is hardly a default package in most distros so no dice.

On Macs, it's supported via MacFUSE, which users still need to install. On Ubuntu, it absolutely is a default package, already there even on the livecd.

Re:ZFS!! (1)

Jesus_666 (702802) | more than 5 years ago | (#25929139)

And suppose I have a portable hard drive, which I want to make sure is readable everywhere -- all I have to do is make a separate FAT32 partition with all the relevant software on it for Windows and OS X to read the other partition.

Tried it, didn't work. In order to do anything meaningful with a non-FAT/NTFS drive under Windows you need to install an IFS. Few people are going to let you install some random driver on their notebook just to access your USB drive. That's also the reason why MacDrive and ext2-IFS are no solutions: While they give you portability under laboratory conditions (between all of your computers), they are useless for exchanging data with others. A FAT killer needs to run out of the box everywhere, period.

That's aso why I don't believe that FUSE will solve the problem. It's in Ubuntu but what about Debian or CentOS or Sabayon (this being three distros I encountered lately on random computers)? And, of course, under OS X it's always a separate install (two even, IIRC), putting it solidly in "why should I install some random driver" territory.

The reason we put up with FAT32 is not high compatibility, it's absolute compatibility. You can stick a FAT32-formatted USB drive into any random comouter you encounter and it will definitely mount with no kind of setup neccessary. Any filesystem that does not meet those criteria is simply no competitor.

Re:ZFS!! (2, Informative)

szaka (1061180) | more than 5 years ago | (#25928875)

ntfs-3g is hardly a default package in most distros

Actually it's available for over 190 distributions [ntfs-3g.org] and it's the default one the most popular ones, e.g. Ubuntu, openSUSE, Fedora, Mandriva, Slackware, etc. Btw, thanks to FUSE, NTFS-3G also works on FreeBSD, NetBSD, OpenSolaris, OS X and some others (more in the way).

Choose ONE! (-1)

Anonymous Coward | more than 5 years ago | (#25927667)

Jeez, choose one FS and stick with it. Instead of one stable implementation you have this whole business of a dozen half-assed implementations again. Because instead of working on existing stuff, Linux coders tend to throw away everything and start from scratch with "their thing". And why? Because the previous thing was half-assed to begin with.

If Linux coders were designing "standards", we'd have TCP/IP, TCP/IP2, TCP/IP3, TCP/IP4-beta5-pre46 and what not.

"ext2, ext3, ReiserFS, XFS, JFS, Reiser4, ext4, Btrfs, and Tux3." This right there shows you what's wrong with Linux.

And seriously, what kind of fucking ridiculous name is Tux3?!

Re:Choose ONE! (1)

bytesex (112972) | more than 5 years ago | (#25927825)

Filesystems are the new 'definitive, authoritive, all-encompassing audio userland' on Linux.

Re:Choose ONE! (2, Interesting)

Anonymous Coward | more than 5 years ago | (#25927967)

because "one size does not fit all." Some file systems handle better in say a database enviroment handling large number of small files while other handle better in something else. If you want a standard fs for general use, that's what ext2 is for as well as ext3(which is backwards compatable with ext2). Can you use another fs other then what most distro decided upon, sure, that's what freedom is about. New implementations are created because they are created with different goals in mind.

Windows is not without it's own choices mind you either, fat(fat16), fat32, ntfs, WinFS(cancelled). As time pass, even microsoft attempts to create a new and improved fs (key-word: attempt). Sure they tend to force the latest fs on you but that's microsoft way VS linux way of choice.

Re:Choose ONE! (1)

dunkelfalke (91624) | more than 5 years ago | (#25928291)

you are quite wrong about windows file systems.
fat16 is dos legacy and isn't used anymore. since windows xp came out, fat32 should be used only for flash memory so there is only ntfs.

winfs never was a filesystem (fs standing for future storage). it was just (more or less) an sql database of file metadata, running of course on top of ntfs.

Re:Choose ONE! (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25928945)

Jeez, choose one FS and stick with it.

Just like everyone else does? Oh wait...

We've got FAT32 for thumb drives, NTFS for Windows hard drives, HFS+ for OS X hard drives, and ISO9660 and UDF for CDs/DVDs -- several versions of them, in fact, with Rock Ridge extensions, Joliet extensions, plus UDF2...

Now, most distros do stick to the standard pattern of one swap partition and one big root partition, formatted as ext3.

However, just like the rest of the world, we recognize that different situations call for different filesystems. UbiFS is a filesystem sitting directly on flash media (instead of above some wear-leveling ATA-emulating layer designed for FAT). sshfs is a (fuse-based) filesystem for accessing remote filesystems via ssh. Squashfs is a read-only, heavily-compressed filesystem, ideal for use on livecds and DVDs. And then there are the journaling filesystems like ext3.

It would be stupid beyond belief to suggest that we should unify those things into one giant, lumbering, monolithic, bloated filesystem.

Instead of one stable implementation you have this whole business of a dozen half-assed implementations again.

Look at the above filesystems I've mentioned. What is half-assed about them? Please be specific.

If Linux coders were designing "standards", we'd have TCP/IP, TCP/IP2, TCP/IP3, TCP/IP4-beta5-pre46 and what not.

Actually, I'm betting quite a lot of Linux coders were designing them -- and the situation isn't far from what you describe.

We still have ipv4 and ipv6. We also have TCP, UDP, and ICMP. We have implementations of TCP over UDP. We have older protocols like AppleTalk and IPX -- dead in most places, but there's a reason Linux still supports them. We have NetBIOS and DNS. We have Zeroconf and Bonjour.

This right there shows you what's wrong with Linux.

Really?

No, filesystems are actually one place Linux is king -- with the possible exception of ZFS, but that's being rectified. We support just about everyone else's filesystems -- from 9pfs to sysvfs, and everything in between. With FUSE, we even support a few filesystems that won't go into the kernel, for technical or legal reasons.

In fact, it speaks quite loudly about the quality of desktop Linux that you think this is what's wrong with Linux. You could have chosen to complain about how slow suspend/resume is on some devices. You could have raged about the lack of support for some obscure wireless card, or whined about being forced to modify your kernel commandline for your touchpad to work.

These might all be valid complaints, but you didn't raise them. Instead, you chose to complain about how many filesystems we have -- how dare we provide so much choice!

And seriously, what kind of fucking ridiculous name is Tux3?!

The same kind of fucking ridiculous name that FAT32 is. Or maybe you like HFS Plus?

WTF - where is FAT?!?! (0)

Anonymous Coward | more than 5 years ago | (#25927699)

I didn't know there was something other than FAT - when did this happen??? Can I get modules for 0.001 beta kernel? ;-)

I use ReiserFS..... (0, Redundant)

ZosX (517789) | more than 5 years ago | (#25927717)

Its a real killer.

Q: Why is starting in the Subject: line annoying? (0, Offtopic)

DNS-and-BIND (461968) | more than 5 years ago | (#25927755)

A: Because it breaks the natural flow of a message.

That may be true... (1)

Chabil Ha' (875116) | more than 5 years ago | (#25927793)

but for grabbing attention, it seems to have worked. It happens all the time--ever watch the evening news?

Problems: IO priority, large #s of files. (4, Interesting)

bboxman (1342573) | more than 5 years ago | (#25927725)

Just my 2 bits. As a user of Linux in a software/algorithm context, my personal beefs with ext3 / the current kernel line are:

1) IO priority isn't linked to to process priority, or at least, not in a decent manner. it is all too easy to lock up the system with one process that is IO heavy (or a multiple of these) -- hurting even high priority processes. As the IO call is handled by a system level (handling buffering, etc.) -- it garners a relatively high priority (possibly falling under the RT scheduler) and as a result IO heavy processes can choke other processes.

2) ext3+nfs simply sucks with very large amount of files. I used to routinely have directories with 500,000 files (very easy to reach such amounts with a cartesian multiplication of options). The result is simply downright appalling performance.

Re:Problems: IO priority, large #s of files. (4, Interesting)

tytso (63275) | more than 5 years ago | (#25927791)

NFS semantics require that the data be stably written on disk before it can be client's RPC request can be acknowledged. This can cause some very nasty performance problems. One of the things that can help is to use a second hard drive to store an external journal. Since the journal is only written during normal operation (you need it when you recover after an system crash), and the writes are contiguous on disk, this eliminates nearly all of the seek delays associated with the journal. If you use data journalling, so that data blocks are written to the journal, the fact that no writes are required means that the data can be written onto stable storage very quickly, and thus will accelerate your NFS clients. If you want things to go _really_ fast, use a battery-backed NVRAM for your external journal device.

Re:Problems: IO priority, large #s of files. (1)

whoever57 (658626) | more than 5 years ago | (#25928205)

NFS semantics require that the data be stably written on disk before it can be client's RPC request can be acknowledged.

Isn't that what the "async" option (to exportfs) is for? To allow the server to respond to the client before the write is complete?

Re:Problems: IO priority, large #s of files. (2, Interesting)

Anonymous Coward | more than 5 years ago | (#25928491)

Sure. If you're a fan of catastrophic data loss, turn on async.

The best NFS (v3) client mount options for a linux server with linux clients vary heavily with what you're actually doing and what you have, but the following is a good start:

sync,hard,intr,nfsvers=3,rsize=32768,wsize=32768,
acregmin=0,acregmax=0, acdirmin=0,acdirmax=10

sync: don't use async! Ever!
hard: better than soft!
intr: allow interruptions despite hard! handy for failure situations!
nfsvers=3: force nfsv3. You DO NOT want to use nfsv2!
rsize,wsize: increase block size to something decent.
acregmin/max: Don't cache regular files. Just don't
acdirmin/max: Cache directories for a _small_ time. Necessary for adequate performance, really, but the smaller while keeping things bearable the better.

Yes, this will make server load pretty high. Get a beefy server. They're cheap nowadays.

Re:Problems: IO priority, large #s of files. (2, Interesting)

pedantic bore (740196) | more than 5 years ago | (#25928645)

NFS semantics require that the data be stably written on disk before it can be client's RPC request can be acknowledged.

This hasn't been true since NFSv2. We're at NFSv4 now...

Re:Problems: IO priority, large #s of files. (2, Interesting)

diegocgteleline.es (653730) | more than 5 years ago | (#25928017)

The CFQ IO scheduler has been able to link IO priority with process priority for ages. But there's a performance issue in the ext3 journaling code that has been affecting many people for some time....

But what about Windows? (1)

kasperd (592156) | more than 5 years ago | (#25927733)

It is rarely an issue to me, but once in a while it is convenient to be able to plug an USB disk on a machine with Windows or Mac OS X. What portable file systems are there that will cover those cases? Last I did some looks around a few years back I ended up concluding that the best option for a file system supported on both Linux and Windows was ext2 (with third party drivers for Windows). The only other file system supported on both was FAT, which have several drawbacks.

Moving forward, what file system will be the most portable? Are we going to be stuck with ext2 and FAT for file systems that we need to access across multiple operating systems, or is there going to be some journaled file system with support for large disks and basic unix semantics?

Re:But what about Windows? (1)

Chabil Ha' (875116) | more than 5 years ago | (#25927807)

Or how 'bout this, why isn't the underlying FS abstracted away from the OS? It seems that if you wanted to get out of the gooey compatibility mess, some sort of common interface would exist independent of OS calls to the hardware.

Re:But what about Windows? (0)

Anonymous Coward | more than 5 years ago | (#25927847)

or is there going to be some journaled file system with support for large disks and basic unix semantics?

Sounds like NTFS...

Re:But what about Windows? (1)

jonbryce (703250) | more than 5 years ago | (#25927853)

HFS+ seems to be the best option. You can get MacDrive for Windows (not free) which provides reasonably decent performance.

Alternatively, there's NTFS. Only problem is that the NTFS3G drivers for Mac have extremely lousy performance. If you use the "stable" drivers, the time to fill a 250GB USB drive is measured in weeks.

Re:But what about Windows? (1)

szaka (1061180) | more than 5 years ago | (#25928155)

The reason for the slow NTFS-3G performance on OSX is the use of the incorrect block device. It could be easily fixed but there is no interest for it.

Re:But what about Windows? (1)

Kent Recal (714863) | more than 5 years ago | (#25928663)

FAT is still the only option last time I checked.
It's the only one that is supported out-of-the-box on every machine (and appliance) that you'll come across.

Re:But what about Windows? (1)

pseudonomous (1389971) | more than 5 years ago | (#25927855)

It would be nice maybe if freeBSD's UFS2 could be adopted, thanks to the BSD licensing anyone could implement it in their kernel so, in principle, it's a perfect fit. There's two sticking points though:

1) Getting people to adopt it and

2) Getting people to adhere to a standard implementation so that that it IS actually a portable filesystem. (look at what happened w/ UFS1)

Re:But what about Windows? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25928951)

After reading a LOT of whiney screeds from Linux people I can pretty well guess where the adoption problem is.

Re:But what about Windows? (1)

Knuckles (8964) | more than 5 years ago | (#25927999)

ntfs comes to mind. It seems well-enough supported in linux distros for data disks you move around.

Re:But what about Windows? (2, Informative)

Ant P. (974313) | more than 5 years ago | (#25928183)

Unless you're dealing with backward firmware/BIOS code that only understands FAT, you should be using UDF. Vista supports it, OS X supports it, Linux supports it, and everything back to win98 has readonly support - but you can get third-party drivers just like for ext2.

Re:But what about Windows? (1)

kasperd (592156) | more than 5 years ago | (#25928317)

you should be using UDF. Vista supports it, OS X supports it, Linux supports it

Maybe a few years down the line that will be an option. Currently the windows systems I would be most interested in exchanging data with are running windows xp. You won't find me pushing for adoptation of new microsoft systems. Maybe I should have made it clear in my previous comment that I was mostly talking about windows xp, and that I only had minor interest in windows 98 and windows vista. But if Linux and Mac OS X both support it out of the box, that would actually be sufficient argument for me to at least try it.

still doing fs on top of RAID :-( (5, Interesting)

r00t (33219) | more than 5 years ago | (#25927779)

We're checksumming free disk space. That's dumb.
It makes RAID rebuilds needlessly slow.

We're unable to adjust redundancy according to
the value that we place on our data. Everything
from the root directory to the access time stamps
gets the same level of redundancy.

The on-disk structure of RAID (the lack of it!)
prevents reasonable recovery. We can handle a
disk that disappears, but not one that gets
some blocks corrupted. We can't even detect it
in normal use; that requires reading all disks.
We have extremely limited transactional ability.
All we get for transactions is a write barrier.
There is no way to map from RAID troubles (not
that we'd detect them) to higher-level structures.

With an integrated system, we could do so much
better. Sadly, it's blocked by an odd sort of
kernel politics. Radical change is hard. Giving
of the simplicity of a layered approach is hard,
even when obviously inferior. There is this idea
that every new kernel component has to fit into
the existing mold, even if the mold is defective.

Re:still doing fs on top of RAID :-( (2, Insightful)

tytso (63275) | more than 5 years ago | (#25927829)

Linux developers are aware of this issue; this is one of the things which is addressed by btrfs.

parodizing _what_, exactly? (1, Funny)

Anonymous Coward | more than 5 years ago | (#25928037)

Could you tell us which song this post is a parody of? Thanks.

Re:still doing fs on top of RAID :-( (4, Insightful)

Blackknight (25168) | more than 5 years ago | (#25928109)

What is this we? ZFS is the fix for all of the issues you mentioned, it does checksums on every block it writes and the RAID 5 write hole is history. You can also set how many copies per file you want to keep.

Re:still doing fs on top of RAID :-( (4, Interesting)

Piranhaa (672441) | more than 5 years ago | (#25928153)

That's the goal of ZFS. Each block is checked with a 256-bit CRC checksum on every access. It incorporates a volume and partition manager in '1 tool', and knows where data is written to. On rebuilds it only repairs data that is actually there, which saves significant time. You should also setup weekly or bi-weekly scrubs (once a month for enterprise grade drives), which reads EVERY block written to and verifies it. This ensures that each block is still good, none is suffering from flipped bits, and that your disk isn't slowly failing on you.

Re:still doing fs on top of RAID :-( (1)

davolfman (1245316) | more than 5 years ago | (#25928181)

Sure you can handle a few corrupt blocks on disk. RAID is built on the assumption that any hard disk has checksumming built right in. Without that RAID 5 would be impossible.

Re:still doing fs on top of RAID :-( (2)

Wesley Felter (138342) | more than 5 years ago | (#25928397)

RAID is built on the assumption that any hard disk has checksumming built right in.

Too bad that assumption is wrong. Despite the ECC in disks, corruption still sneaks in.

http://www.usenix.org/event/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html [usenix.org]

To fix this you can use either ZFS-style integrated filesystem and RAID or 3Par/Xiotech/XIV-style chunk RAID with checksums and unmap bad parts of the disk.

Re:still doing fs on top of RAID :-( (0)

Anonymous Coward | more than 5 years ago | (#25928569)

Sun's SAM/QFS is an HFS that allows adjusting redundancy and backing storage based on criteria you establish. It was open sourced under Sun's license.

http://opensolaris.org/os/project/samqfs/ [opensolaris.org] has information about the project

Hammer filesystem, up and coming..... (1)

3seas (184403) | more than 5 years ago | (#25927811)

worth a mention for large media space.

http://www.dragonflybsd.org/hammer/index.shtml [dragonflybsd.org]

Re:Hammer filesystem, up and coming..... (0)

Anonymous Coward | more than 5 years ago | (#25927873)

Too bad you can't "touch" in it.

But... (2, Funny)

El_Muerte_TDS (592157) | more than 5 years ago | (#25927821)

is it ready for the desktop?

I propose a new file system.. (5, Funny)

Minigun_Fiend (909620) | more than 5 years ago | (#25927849)

..called TLDRFS It simply ignores any files larger than 64KB.

What a File system needs to provide: (0)

Anonymous Coward | more than 5 years ago | (#25927973)

This seems such a popularity contest. I usually don't know why I'd want one FS over another.

I propose we make a list of OS features that are desirable, and gravitate towards the one that can provide em all.

1) Transparency. Should be easy to move data from disk/vol to disk/vol at/near rated speed of interface.

2) On line snapshot via COW for online maint etc.

3) Journaling to ensure compatibility with power-offs. (control over where logs go too!).

4) Compatible with LVM structures.

5) Compatible with RAID structures.

6) variable block sizes.

7) Fast search via name or metadata.

8) Good with lots of little files

9) Good with GIANT files too

10) Mandatory Access Controls

11) Read only as needed.

12) Noatime as needed.

13) On line defrag/reorg.

Basically, I need to perform maint on File System, as well as needing to provide for operational adjustments for Speed or Security or End-User-Shutdowns.

14) Rsync from a block level would be nice too!

Just a few things. Am sure there are many more.

Perhaps the various F/S out there might be listed by a plusses/minuses rating level for a set of features.

I had used XFS a few years back and was amazed at how fault tolerant it is. (slow with lots of little files, but.... rocked otherwise.

JWest

XFS was (and is) pretty nice (2, Interesting)

Britz (170620) | more than 5 years ago | (#25928007)

Maybe not for a desktop machine, but for servers I like to use XFS. That started way back then when XFS was the first (and then only AFAIR) fs that supported running on softraid. It was not that long ago and CPU cycles were already so cheap on x86 that softaid was already a pretty nice solution for small servers.

For small servers I have not changed that setup (XFS on softraid level one on two cheap drives) ever since.

I guess for the big machines it might be very different. I am pretty happy with XFS as it is.

Re:XFS was (and is) pretty nice (1)

springbox (853816) | more than 5 years ago | (#25928621)

I found JFS to perform better than XFS, especially with I/O throughput.

What is more needed is a modern multi-platform FS (1)

rduke15 (721841) | more than 5 years ago | (#25928075)

I don't really care about better filesystems. ext3, NTFS and Mac OS Extended seem to be extremely reliable and work perfectly well on their respective platform.

The only real problem I have is there doesn't exist a modern journaling FS which would work just as well on all 3 platforms.

I can use ext3, but cannot plug it into a Mac.

I can use Mac's FS, but cannot plug it into Windows (unless I pay for a proprietary driver every time I use that disk on a different machine)

I can use NTFS, but cannot write to it on a Mac.

This is the real problem I have. I would like one of these 3 (preferably the open source ext3) to have perfect support on both of the other 2 OSes. And if there is a serious such project for ext3, I would be glad to contribute with a donation.

Re:What is more needed is a modern multi-platform (1)

Enderandrew (866215) | more than 5 years ago | (#25928163)

Exactly. I can use ext3 in Windows, but only if I mount ext3 with the right options. For instance, when I installed openSUSE 11 on my dual-boot box, I decided to use writeback for journaling, and now none of the ext3 options for Windows can mount that drive. ntfs in Linux is painfully slow, even with ntfs-3g.

I'm looking to build my next box with 4 x 1.5TB drives and I'm debating how to partition and format it for a dual-boot Windows/Linux setup. Do I keep most of shared media (I'm going to rip my entire DVD collection, not to mentiom my emulator/rom collection, e-books, MP3's, etc) on NTFS or EXT3?

Re:What is more needed is a modern multi-platform (1)

ultranova (717540) | more than 5 years ago | (#25928963)

For instance, when I installed openSUSE 11 on my dual-boot box, I decided to use writeback for journaling, and now none of the ext3 options for Windows can mount that drive.

Ext3 is actually ext2 with a special file used for journaling. In fact you can create this journal on existing ext2 partitions to "convert" them to ext3. Assuming that the machine was shut down correctly, and all the data in the journal has thus been flushed to the disk, ext2 tools should mount it just fine as an ext2 volume - and if they don't, it's time to run fsck and fear the worst.

Re:What is more needed is a modern multi-platform (1)

kayoshiii (1099149) | more than 5 years ago | (#25928427)

Well actually if you install drivers you can access ext3 on Mac. There is also a third party read write ntfs driver for Mac (but is slow) - But the point being that it would be nice to be able to use a filesystem out of the box on Mac/Windows/Linux that supports larger than 2GB file sizes

Re:What is more needed is a modern multi-platform (2, Informative)

TrekkieGod (627867) | more than 5 years ago | (#25928431)

The only real problem I have is there doesn't exist a modern journaling FS which would work just as well on all 3 platforms.

I agree with you that's really important. I'd also like zfs to be that filesystem. However, as long as you don't need that drive to be the root drive of your respective file system, you might be interested in some of these links:

I can use ext3, but cannot plug it into a Mac.

Give this [sourceforge.net] a try. The latest news is that you get write support in Tiger, but I use it in Leopard without problems.

Also don't worry about the ext2 part. Ext3 is designed to be backwards compatible with ext2. It can be mounted as ext2 (it just won't get journaling)

You didn't ask for it, so you might already know about this [fs-driver.org] windows driver. There are actually a couple out there, I think that one works the best (which is kind of unfortunate, because it's freeware, but proprietary).

I can use NTFS, but cannot write to it on a Mac.

Sure you can, same way you do it in Linux, through fuse and ntfs-3g [blogspot.com] .

I can use Mac's FS, but cannot plug it into Windows (unless I pay for a proprietary driver every time I use that disk on a different machine)

Yeah, you got me there. MacDrive works really well, but I'd like a non-proprietary version myself.

For a removable drive that you can plug in anywhere, I'd go with ntfs actually. No FAT size restrictions, no permissions (actually a plus for a removable drive), and most linux distributions come with ntfs-3g installed by default. That means you only have to install the driver in mac os x

Reiser4 (4, Interesting)

Enderandrew (866215) | more than 5 years ago | (#25928149)

Hans was a jerk who has difficult to work with, and now he is a convicted murderer. That doesn't change the fact that Reiser4 as is may be the best desktop file system for Linux users, even with plenty of room for improvement.

There are filesystems in development like Btrfs and Tux3 that look promising, but why should Reiser4 be abandoned? It is GPL. Anyone can pick it up and maintain it, or fork it.

Does anyone know anything about the future of Reiser4?

Re:Reiser4 (0)

Anonymous Coward | more than 5 years ago | (#25928217)

I guess nobody wants to be murdered for taking over his pet project when he eventually comes out...

Well, yeah. bad joke, but I guess it's on the list of concerns for those who have given the idea some serious thought.

Re:Reiser4 (5, Interesting)

Ant P. (974313) | more than 5 years ago | (#25928281)

Reiser4 is still being maintained, by one ex-Namesys person IIRC.
The main problem is the Linux kernel devs - they were too busy trying to find reasons to keep it out of the kernel (I can agree with their complaints about code formatting, but after that they descend deep into BS-land) to actually improve it. From the outside it sounds a lot like the story about the RSDL scheduler - completely snubbed because it stepped on the toes of one kernel dev and his pet project.

Reiser4's name is a killer (4, Insightful)

acb (2797) | more than 5 years ago | (#25928955)

Over and above this, it'll need a new name. I know it doesn't make one iota technical difference, but people are fussy about such things; change the name, and people don't care if it was developed by fiends. Keep it and people will find excuses to edge away and it'll wither on the vine.

The Volkswagen was a runaway success despite its Nazi origins, but had it been named the "Hitlerwagen", things would have probably turned out a lot differently.

Re:Reiser4 (1)

mrchaotica (681592) | more than 5 years ago | (#25928833)

They need to give Hans an Internet connection in his cell. At least then he can still be of some use to society, and it's not as if his was a computer-related offense...

A metaphysical question (2, Interesting)

millosh (890186) | more than 5 years ago | (#25928269)

Whenever I have to install some server, I have a metaphysical question: ext3 or reiserfs?

Ext3 has a lot of advantages, including a possibility to do a fast recovery of files. While it is not needed often, at least once per year I have such demand. At the other side, undelete methods with raiserfs are very problematic.

At the other side, my servers are up usually for a year or more. This means that the most of company's employees may go on one day vacation whenever I want to reboot a machine with 4TB file system.

Any good idea to solve those two issues with one file system?

Re:A metaphysical question (1)

LWATCDR (28044) | more than 5 years ago | (#25928303)

JFS?

Re:A metaphysical question (1)

tytso (63275) | more than 5 years ago | (#25928999)

The ext2/ext3/ext4 filesystems do a periodic check of the filesystem for correctness out of paranoia; because PC class disks, well, have the reliability of PC class disks, and that's what most people use these days on Linux systems. Other filesystems, such as reiserfs and xfs, are subject to the same kind of potential random filesystem corruption caused by hardware errors that ext3 is; in fact, in some cases their filesystem formats are more brittle than ext2/3/4 against random hardware failures in that a single bad block that corrupts the root node of a reiserfs filesystem, for example, can be catastrophic. It's just that their filesystem checkers don't require doing a periodic check based on time and/or the number of mounts.

If you want to configure ext3 filesystems to have the same happy-go-lucky attitudes towards assuming hard drives never fail as reiserfs, you can do so; it's just a matter of using the tune2fs program; check out the man page options for the -c and -i options to tune2fs. Then you won't do a filesystem check at reboot time.

What I do recommend, especially if you are using LVM anyway, is periodically (say, once a month, Sundays at 2am, or at some other low utilization period), have a cron script run that takes a snapshot of your filesystem, runs e2fsck on the snapshot, and if it has errors, sends e-mail to the system administrator advising them that it is time to schedule downtime to have the filesystem corruption repaired. This has the best of both worlds; you can now do much more frequent checks to make sure the filesystem is consistent, and you don't have to take the system down for long periods of time to do the test, since you can run e2fsck on the snapshot while keeping the system live.

JFS (4, Insightful)

adrianbaugh (696007) | more than 5 years ago | (#25928915)

Sad to see JFS being overlooked so. While it may not have the postmodern features to compete in the wake of JFS, it's still in many cases the best current filesystem for linux. It's remarkably crashproof, has the lowest CPU loading of any of {ext3 jfs xfs reiser3}, good all-round performance (generally either first or second in benchmarks) and is fast at deleting big files. I haven't used anything else in a couple of years - I used to put reiser3 on /var, but got fed up with its crash intolerance. It's sad to see jfs so overlooked, because at least until btrfs or tux3 come out it's arguably the best option available.

OSS - reinventing the wheel (2, Insightful)

Anonymous Coward | more than 5 years ago | (#25928935)

seriously how many filesystems do we need? this is the failing of OSS, too many projects inventing the same thing splitting up their developing efforts so neither of them achieve anything.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?