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!

XFS 1.0 is Released

CmdrTaco posted more than 13 years ago | from the journaling-is-spiffy dept.

Technology 173

Isldeur was the first of many to note that SGIs now open source Journaling File System "XFS" has announced the release of version 1.0. It, Reiser, the new ext format continue to be an area of debate, but regardless, Journaling file systems are nice to eliminate those slow fsck boot ups, and to protect all your pr0n when you lose power and realize that you plugged the UPS into your stereo by mistake (not that I've done that. No sir.)

cancel ×

173 comments

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

Re:Booting (1)

Anonymous Coward | more than 13 years ago | (#253445)

SGI has a modified version of the anaconda installer from Redhat 7.x that allows you to install a 100% XFS system. I have three servers running all XFS filesystems and I love it. Full lilo support, no problems. It would be nice to have XFS added to the stock kernel. Maybe someday.

Re:okay okay.... I'm not informed... (1)

Anonymous Coward | more than 13 years ago | (#253446)

A lot of sourceforge.net servers have been running reiser for many months. not a bad proving ground

Re:Standardization (1)

Anonymous Coward | more than 13 years ago | (#253447)

There really isn't any reason for your concern. You may remember that EXT2 was not Linux's first and only filesystem. There have always been competitors and predecessors: minixfs, xiafs, ext. If you care to flesh your worries out and explain SPECIFICALLY why and in what situations you think having more than one excellent filesystem for Linux is going to be a problem, it could then be discussed further - otherwise you're either posting mindless drivel or deliberately trolling. Many people I know use Reiserfs or EXT2 in combination with Reiserfs. And so far there's yet to be any compatibility problem at all between them. Reisefs has incompatibities with certain software RAID setups and NFS, so if those things are more important to you than Reiser's journalling, you use ext2. XFS is a truly excellent fs, as is IBM's JFS. EXT3 may provide people with EXT2 systems a painless conversion path to a journalling system. They are all better at different things.

This filesystem agnosticism is a wonderful and fairly unique feature of Linux, not a problem, and it's not a new thing - just the luxury of many journalling systems is new.

Real issue is HARD DRIVE CACHEs. (1)

Anonymous Coward | more than 13 years ago | (#253448)

The kernel can only ask the hard drive to flush the data to disk. The disk need not comply, despite returning a "yes I did" result. And as large drives have 5 and 10MB caches now, how can the consumer really know what the drive decides to do? It may do write caching so marketroids can boost performance specs. This stuff is not document on the box the hard drive comes in nor on the mfg web site.

Re:okay okay.... I'm not informed... (2)

Anonymous Coward | more than 13 years ago | (#253450)

Can we please /please/ have an "Uninformed" or "Ignorant" or "Just Plain Wrong" moderation option for posts like the above? That crap got modded /up/ because the moderators don't have a clue either, but it's just /full/ of misinformation.

Re:Nice FS, shame about the license (2)

Anonymous Coward | more than 13 years ago | (#253451)

Could you PLEASE come to the realization that "microsoft or any other company" CANNOT "close" open source BSDL'd software? Software is not physical object. When someone takes a copy, regardless of what they do to it, the original is STILL THERE.

Re:okay okay.... I'm not informed... (3)

Anonymous Coward | more than 13 years ago | (#253452)

Yes, XFS is proven on IRIX, XFS is not proven on Linux, Reiserfs is proven on Linux (shipping with SuSE for almost two years now).

Re:Nice FS, shame about the license (3)

Anonymous Coward | more than 13 years ago | (#253453)

Had they placed it under a BSD license perhaps it might actually get some use. But oh well.

Had they placed it under a BSD license, effort that has been put into producing an open and free filesystem could be closed by a company such as Microsoft. Why should I let them profit if they don't contribute or at least acknowledge my work?

As it is, xfs is under the GNU GPL and is thus protected from being made proprietary. The GPL protects the rights of free software authors. Myself, and thousands of other free software developers worldwide, wouldn't have it any other way.

Re:journaling is nice, but how about a better RAID (3)

Anonymous Coward | more than 13 years ago | (#253454)

I just upgraded my home network to 100baseT. Now, how the hell am I going to saturate a 100Mbps link with a shitty IDE hard drive, or even a faster SCSI?

#hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec
Timing buffered disk reads: 64 MB in 2.94 seconds = 21.77 MB/sec

Observe the time taken during the buffered disk read test - 21.77 MB/sec. This is on my year-old Athlon system. AFAIK 100mbit networks don't tend to transfer data at speeds faster than 10 MB/sec. Perhaps you meant that you upgraded your home network to gigabit. Or not.

Use hdparm to ensure that your hard drive is set to use DMA.

Filesystem info (5)

Anonymous Coward | more than 13 years ago | (#253455)

For those of you looking for comparisons, why not check http://www.softpanorama.org/Internals/filesystems. shtml which appears to have links to information on a variety of filesystems (most of the journalled FSs under Linux) and even NTFS.

Re:okay okay.... I'm not informed... (5)

Anonymous Coward | more than 13 years ago | (#253456)

SGI is going to put Linux on their Big Systems(tm) when the Itanium-class CPUs start shipping. They've been planning this for a while now. The current generation of Onyx/Origin boxen are designed with multiple CPU architectures in mind -- e.g. you will be able to have a MIPS system or an IA-64 system just by swapping a single brick.

The eventual plan is to have Linux for the Intel servers and IRIX on the MIPS ones, with IRIX being phased out over a long period of time so as to keep the old customers from getting paranoid. There's even rumors internally about servers with *BOTH* intel and MIPS processors in them running Linux. If you watch SGI's Linux pages, you'll notice that more and more support is made available for running Linux on R10K, R12K and other heavy-duty processors, not to mention SGI's memory architectures (e.g. ccNUMA).

My own theory is that the now-EOLed 320/540 workstations were an experiment to see how SGI's customer base would react to non-MIPS/IRIX workstations and to get everyone warm to the idea of SGI branching out.

SGI is a company to watch over the next few years, and releasing things like open-sourced XFS for Linux are just teasers of what's to come.

SGI's XFS page: (4)

Wakko Warner (324) | more than 13 years ago | (#253461)

For more about XFS, SGI's official page is here [sgi.com] .

- A.P.

--
Forget Napster. Why not really break the law?

What happend to Tux2? (4)

gjohnson (1557) | more than 13 years ago | (#253466)

Speaking of journaling filesystems, what ever happend to tux2? Was any code ever released?

tux2 looked really good. Supposed to be faster than traditional journaling, and preserves file data as well as metadata.

Anyone?

The Current Tally... (5)

jd (1658) | more than 13 years ago | (#253467)

There are a LOT of journalling filesystems for Linux. Excluding extensions (which effectively double the number of unique systems), there are five "genuine" journalling filesystems for Linux.

(I don't count NTFS, because that is hard-pushed enough to be called a genuine filesystem, never mind a journalling one.)

Feel free to reply to this, adding any that I've missed.

The Logging filesystem does much the same thing as Ext3 - it is an extension to Ext2 - but it looks like it would be a lot more useful than Ext3. IMHO, it'd be much better if neither of them were so FS-specific and could be used as a generic wrapper. SnapFS does exactly this, for example.

Anyway, on with the list of Journalling Filling systems...

... -IN- the main kernel tree:

... at a stable release:

  • XFS [sgi.com]

... at a developmental release:

... currently abandoned:

... extensions for:

Re:pondering (1)

Paul Jakma (2677) | more than 13 years ago | (#253468)

The only SGI systems that run Linux right now are the low-end Intel workstations

balderdash... SGI have people working on MIPS and they have linux running on Origin2000 with *128* CPUs. Granted, the work seems primarily intended to develop linux so that it can be suitable for use on the IA64 O3000s, but you're still talking bollocks.

See:

http://oss.sgi.com/projects/LinuxScalability/downl oad/mips128.announce [sgi.com]

and

http://oss.sgi.com/projects/LinuxScalability/downl oad/mips64.announce [sgi.com]

And linux also runs fine on many /low-end/ MIPS boxen too. Eg, handhelds, embedded boards, etc. Also runs fine on my MIPS R4k Indy...

--paulj

Re:works with samba 2.2 acl's ? (2)

Booker (6173) | more than 13 years ago | (#253473)

test-2, test-3, and 1.0 have been released since then, and that includes an acl fix. Without knowing for sure what your problem is, hard to say for sure if your specific problem has been resolved...

Oh, and as for fs conversion... (2)

Booker (6173) | more than 13 years ago | (#253474)

Can you convert a drive you've already got data on? Could I simply point at my disk drive and say, "turn that into an XFS drive," edit a few boot params, and be done?

No, sorry. :) that'd be quite an undertaking. You can dump/restore between filesystems, or just copy over, but there is no magic "ext2 to xfs converter."

Debian Install Disks? (3)

Booker (6173) | more than 13 years ago | (#253476)

At this point, SGI has only provided an unsupported Red Hat system installer for XFS. However, there are a couple people in the Linux community who have been working on Debian packaging & installers, and also someone working on slackware. Check the xfs mailing list archives for more info...

GRIO / Realtime (3)

Booker (6173) | more than 13 years ago | (#253477)

FWIW, GRIO and realtime subvolumes (err... partitions in the Linux case) are not yet implemented in Linux.

Re:Tar Ball, etc (4)

Booker (6173) | more than 13 years ago | (#253479)

The kernel & userspace utils are packaged several different ways - cvs, patches, tarballs, rpms etc.

Go to http://oss.sgi.com/projects/xfs for the info.

Get SGI's installer (4)

Booker (6173) | more than 13 years ago | (#253480)

We have a system installer that works with Red Hat 7.1 to do exactly what you're asking about. Grab our iso, burn a cd, boot from it, and you're on your way. You'll need the Red Hat 7.1 cds as well.

The other option, of course, is to have lots of extra space, install your distro, boot an XFS capable kernel, make some XFS filesystems, and copy everything over.

Re:Booting (5)

Booker (6173) | more than 13 years ago | (#253481)

Lilo in the MBR works just fine with XFS. There are no issues, I have 3 machines that boot that way.

2.4.4 is 3 days old. (5)

Booker (6173) | more than 13 years ago | (#253482)

A lot of people have been complaining that there is no 2.4.4 patch - but bear in mind that 2.4.4 is only 3 days old. We'd be a bit nuts to release 1.0 on a kernel as untested as that.

On the other hand, the devel cvs tree is usually updated within a few days of a new kernel release. As soon as the kinks get out of XFS+2.4.4, it'll be in the devel cvs tree.

The majority of our 1.0 testing has been done on 2.4.2, so we have the most confidence in XFS there. We also have a 2.4.3 patch which should be fine, although it has not had as much direct testing.

We realize that there are issues with 2.4.2 (loop device, anyone?) If you're concerned about fix-ups, and you run an RPM-based systems, you might take a look at the Red Hat kernel RPMs we offer - those include a ton of patches from Red Hat - essentially the same kernel as shipped with 7.1, with XFS added.

If you're concerned about netfilter, just get the patch - I would be very surprised if it conflicted in any way with an XFS-enabled kernel.

Re:NT (1)

Mike Buddha (10734) | more than 13 years ago | (#253486)

How is this an advancement on NT, which has had journaling features since NT 4.0

Well, you can use this with a useful OS for one, instead of a knucklehead joke OS like NT or W2K.

Re:Booting (1)

pivo (11957) | more than 13 years ago | (#253490)

As far as I know Reiser does not yet support root file systems (necessary for booting) but according to the story, XFS does so yes, you should be able to have a completely journaled FS.

Tux2 (4)

geoffeg (15786) | more than 13 years ago | (#253493)

I keep hearing little tidbits about Tux2 (Tux2: The Filesystem That Would Be King [slashdot.org] ). I can't find Daniel Phillips's website anymore nor have I seen any more information about it in the last few months. What I have read and heard about it sounded very interesting (I would say it's sounds promising but I don't know enough about file systems to know how good an idea it is realistically).

Would this be under "currently abandonded" or "abducted by aliens"?

GeoffEG

Re:okay okay.... I'm not informed... (2)

lupetto (16876) | more than 13 years ago | (#253496)

I have not used Reiser, so I can't speak to it's performance.

However, I can tell you that XFS is a really great filesystem. We have over 100 Irix/XFS systems deployed at television stations around the world. These systems are very I/O intensive, and I have never had a corrupt filesystem. Performance is also very good.

I would really like to see SGI copy more features from Irix into Linux, such as fine control over process priorities, something standard linux distributions are severely lacking, imo.

Re:Performance (1)

Petrus (17053) | more than 13 years ago | (#253497)

I gess, that he did not mean to say that the link is broken. He means, that while the mail claims, that there are comparisons of XFS to other journaling FS, which is worong. It compares another journaling fs (ReiserFS) with non-jurnaling ext2fs, instead.

Yet I liked to know about that comparison, too.

my exp with reiser (1)

Scudsucker (17617) | more than 13 years ago | (#253498)

Reiser is pretty nifty on my two 40 gig mp3 drives; I'm also using it for /home and /usr and am pretty happy with it.

One cavet: the version of reiser that comes with 2.4.x is incompatible with the versions for 2.2 kernels. Strange, as most distro's still use 2.2.... It was quite frustrating to back up my 50 gigs of mp3's to reformat my ext2 partitions, only to have to rebackup and reformat to the older reiserfs so it would work with 2.2.19.

Criteria how to choose file systems? (2)

Stentapp (19941) | more than 13 years ago | (#253504)

Since some file systems fits some purposes better than other file systems, and other file systems fits other purposes better than some file systems, what criterias do you have to consider when selecting a file system from another?

Re:pondering (2)

irix (22687) | more than 13 years ago | (#253505)

All this moderation is getting bad posts modded up waaay too much...

As it stands right now the majority of their hardware run Linux

Umm, not really [sgi.com] . And the hardware that does run Linux runs it with beta-type quality.

the last version of Irix released was to mainly fix bugs.

No shit. They release quarterly maintenance releases - in the 6.5.X series - up to 6.5.11 now.

They will probably drop IRIX someday down the road. But since the workstation marked imploded on them, SGI is trying to make money off of servers. I don't think that Linux is going to be running (release quality) 256-way Origin servers any time in the "near future".

Re:Booting (2)

churchr (24226) | more than 13 years ago | (#253507)

GRUB is great. I love GRUB. However, GRUB has this problem _even more_ than LILO. LILO is FS agnostic. It tries to load the kernel from a specified _disk block_.

GRUB, on the other hand, actually reads the file system, like the BSD bootloaders, and at this point, it doesn't know how to read XFS.

Re:okay okay.... I'm not informed... (1)

ianezz (31449) | more than 13 years ago | (#253508)

How can the filesystem code possibly know when data is on the disk when the kernel is caching it

Simple: it doesn't know when data is on the disk, because with common hardware you can't. Hard disks have their onboard (volatile) memory, and write operations report as completed when data reach the cache of the disk, which IIRC can't be controlled by software.

Someone once told me SGI has a smart disk controller backed up with a battery, so in the event of a blackout, the controller would keep for some hours the data still not written on the disk, flushing it on the disk on the next power up.

Re:VMWare (2)

jmauro (32523) | more than 13 years ago | (#253511)

It works fine, but is a little unhappy because it does not recongize the filesystem and spits out information asking if locking is ok or not. Kind of sucks, but other than that it works.

Booting (5)

Spyffe (32976) | more than 13 years ago | (#253512)

It seems like one of the nastiest problems when you want to promote a new filesystem is getting LILO, SILO, MILO... to load a kernel image off of the filesystem. What are the issues involved here? Do these loaders really only support ext2fs? If so, this would prevent a user from having a completely journalled system, right? Perhaps there are ways of fixing this (like backups of the /boot partition on a journaled fs) but it would be cool (I think) to have a mini-fsck run on the boot partition before the kernel boots. There may be issues here; perhaps a MD5 sum or something of the sort might be better to check that the boot partition is uncorrupted. The sum would be checked against... what? This post is as much an RFC as anything else. Go at it!

Performance (2)

eric2hill (33085) | more than 13 years ago | (#253513)

So does anyone know (benchmark wise that is) how XFS performs compared to reiser, ext3, etc.?

Re:okay okay.... I'm not informed... (3)

Salamander (33735) | more than 13 years ago | (#253514)

Wouldn't you just be mirroring if you wrote user data to the log?

Not quite. The log/journal is structurally different than the main data areas, with different synchronization and performance characteristics. Writing once to the log and once to the main data area is quite different than writing twice to the main data area.

However, an observation very similar to yours is behind log-structured filesystems. In other words, if you're going to write all the data to the log in a highly robust etc. way, why not just make the log the authoritative copy of the data? There's a whole lot of gunk that has to be worked out after that, such as how you find data and how you reclaim log space, but it all flows pretty cleanly from that initial idea. The result is pretty nifty for some kinds of workloads, but in general changing OS structures and their effects on I/O patterns have sort of left log-structured filesystems behind.

If you're interested in exploring further, the seminal papers in this area are The Design and Implementation of a Log-Structured File System [nec.com] by Rosenblum et al, and (IMO even better) An Implementation of a LogStructured File System for UNIX [nec.com] by Seltzer et al. Enjoy!

Re:okay okay.... I'm not informed... (3)

Salamander (33735) | more than 13 years ago | (#253515)

Someone once told me SGI has a smart disk controller backed up with a battery, so in the event of a blackout, the controller would keep for some hours the data still not written on the disk, flushing it on the disk on the next power up.

Interesting. I dunno about the SGI product, but the EMC Symmetrix takes a different approach. It has enough reserve power so that if it detects loss of external power it will immediately flush its cache to special areas on disk. Then, the first thing it does when it comes back up is slurp all that data back into cache - which not only ensures data stability but preloads the cache for you as well. Cool. I've heard that in a simulated blackout in a big data center everything would get eerily quiet *except* for the Symmetrix, which would actually get extra-loud as it does the flush.

Disclaimer: I work for EMC. I don't speak for them, they don't speak for me, yadda yadda yadda.

Re:Real issue is HARD DRIVE CACHEs. (4)

Salamander (33735) | more than 13 years ago | (#253516)

The kernel can only ask the hard drive to flush the data to disk. The disk need not comply, despite returning a "yes I did" result.

That's an important issue. I'll try to provide a couple of answers.

how can the consumer really know what the drive decides to do?

Well, there are at least two ways:

  1. Turn off write caching.
  2. Set the "Force Unit Access" (FUA) bit on the Write command, if it's a SCSI/FC disk.

SCSI gives you other options as well. For example, if you're using tagged command queuing, you can set FUA only on the last command of a sequence (e.g. a transaction). That way, you can allow the disk or storage subsystem to do appropriate reordering, combining, etc. and you'll still be sure that by the time that last command completes all the commands logically ahead of it (as specified by the tags) have completed as well. It's tres cool, and it's one of SCSI's biggest benefits compared to IDE.

Tagged command queuing also comes in handy if you have to force write caching off - which BTW is common and not particularly difficult on either SCSI or IDE drives. Since you're now forced to deal with full rotational latency, the importance of overlapping unrelated operations (by putting them on different queues) becomes even greater.

This stuff is not document on the box the hard drive comes in nor on the mfg web site.

Tsk tsk, that's a shame. It's pretty common knowledge among storage types, but still far from universal. Go look on comp.arch.storage and you'll see a recurring pattern of people finding this out for the first time and sparking a brief flurry of posts by asking about it.

The problem with having the drive notify the host that a write has been fully destaged is that target-initiated communication (aside from reconnecting to service an earlier request) is poorly supported even in SCSI. Hell, it's even hard to talk about it without tripping over the "initiator" (host) vs. "target" (disk) terminology. Most devices lack the capability to make requests in that direction, and most host adapters (not to mention drivers) lack support for receiving them. AEN was the least-implemented feature in SCSI.

There's also a performance issue. Certainly you don't want to be generating interrupts by having the disk call back for *every* request, but only for selected requests of particular interest. So now you need to add a flag to the CDB to indicate that a callback is required. You need to go through the whole nasty SCSI standards process to determine where the flag goes, how requests are identified in the callback, etc. Then you need every OS, driver, adapter, controller, etc. to add support for propagating the flag and handling the callback. Ugh.

It's a great idea, really it is. It's The Right Way(tm). But it's just never going to happen in the IDE world, and it's almost as unlikely in the SCSI/FC world. 1394 seems a little more amenable to this, but I have no idea whether it's actually done (I doubt it) because even though I know they exist I've never actually seen a 1394 drive close up.

I hope all this helps shed some light on the subject.

Re:okay okay.... I'm not informed... (5)

Salamander (33735) | more than 13 years ago | (#253517)

The difference is that Reiser is NOT a journaling filesystem (well, not any more that, say, NT or BSD UFS filesystems are), since it only journals the meta data

So does XFS. From one of SGI's own presentations [sgi.com] :

5.6. Supporting Fast Crash Recovery
...To avoid these problems, XFS uses a write ahead logging scheme that enables atomic updates of the file system. This scheme is very similar to the one described very thoroughly in [Hisgen93].
XFS logs all structural updates to the file system metadata. This includes inodes, directory blocks, free extent tree blocks, inode allocation tree blocks, file extent map blocks, AG header blocks, and the superblock. XFS does not log user data.

[emphasis added]

This is *normal* for a journaling filesystem. Very very few actually log or otherwise protect file data, because of the cost. Maintaining a metadata-only log is already a significant performance limiter, and journaling data as well would just be prohibitively expensive. Most users wouldn't even want it, if they had to pay the performance cost.

Re:The Current Tally... (1)

NCamero (35481) | more than 13 years ago | (#253518)

NTFS does count as a genuine journaling filesystem. But Microsoft's Linux/GNU driver is of inferior quality.

Re:NT (1)

ttfkam (37064) | more than 13 years ago | (#253519)

NT 4 w/ journaling hunh? I've heard the same rumor, but I've also waited quite a while while waiting for the filesystem check after a BSOD (and yes, they were NTFS partitions).

And has anyone ever had a boot partition go south on NT 4? I have a few times. Once by my fault and twice by some weird NT voodoo after a blue screen of death.

Win2000 is definitely an improvement, but you have way too much love for NT 4.

XFS installer (5)

ttfkam (37064) | more than 13 years ago | (#253520)

I have been using XFS on my home machines since v0.9. The installer has had a couple of glitches in the past (0.9 left me without access to the network and my cdrom drive by default). The recent beta fixed a lot of problems and was based on RedHat 7.1 (as opposed to 7.1 betas from earlier releases).

I haven't tried the 1.0 release yet. There's only so many hours in the day. On the other hand, the last install I did with the beta, after installing everything I wanted, I fired up a dozen programs such as Mozilla, GIMP, Nautilus, etc. While the drive was churning, I hit the power switch. For those of you who have used ReiserFS, I'm sure this is no big deal. ;)

It should be noticed that on my Athlon 800MHz w/ 128MB of RAM and a 27GB hard drive, I almost missed the filesystem check as it scrolled by on bootup. That had me sold forever on journaling filesystems.

I haven't seen any visible performance differnece though. There may be, but so much has changed on my system that any subjective comparisons are almost impossible/meaningless. For example, devfs is enabled by default, there's a more up-to-date kernel and the drive has a different partition layout. Who could tell what the FS performance difference may be. I definitely don't need to go back to ext2 just to see if my switchover was justified. Any more info will just be icing.

If someone wants to post "real" benchmarks (lies, damn lies, and all that) I'd love to see them too.

Re:journaling is nice, but how about a better RAID (1)

Tower (37395) | more than 13 years ago | (#253521)

My old Connor 212MB IDE can't... it still works though... half height, doesn't hold data, works great on a 386...

though any EIDE drive since ~1997 should be able to keep up with a 100Mb channel...

--

Ext3 (2)

macdaddy (38372) | more than 13 years ago | (#253522)

Does anyone have a good comparison of XFS, Ext3 and other journaling filesystems? I know Ext3 is being used on rpmfind.net [rpmfind.net] , also know as rufus.w3.org [w3.org] , and it works very well there. I'd like to give XFS or Ext3 a whirl but I don't have time to search out all the gotchas myself.

--

But how do you USE it? (2)

DrKirwin (38614) | more than 13 years ago | (#253524)

I've not looked at the docs, but this question is kind of applicable to all the journalled file systems and something I've been curious about:

How do you get them to work with, say, RedHat, from an installation standpoint? (I imagine it's relatively easy to convert an extra disk attached to an already installed Linux box, but what about making your whole system with the new FS?)

At no point does RedHat ask me which filesystem I'd like to install, so that option is out (except for Mandrake and Suse?).

Can you convert a drive you've already got data on? Could I simply point at my disk drive and say, "turn that into an XFS drive," edit a few boot params, and be done?

Surely, it's more complicated.

Have any of you done something similar?

Any recommendations on how to get it working with the least amount of hassle?

Just curious.

Re:pondering (2)

bdrago (42295) | more than 13 years ago | (#253526)

Wow. This is MS-qualify FUD.

I wonder if folks over at SGI plan on dropping Irix in the near future for Linux entirely. As it stands right now the majority of their hardware run Linux, and the last version of Irix released was to mainly fix bugs.

The only SGI systems that run Linux right now are the low-end Intel workstations (230, 330, and 550) and the Intel rack-mount servers (1100, 1200, 1400, 1450) - certainly not a "majority of [our] hardware.

IRIX on MIPS is not going anywhere. Take a look at SGI's IRIX/MIPS roadmap. [sgi.com]

Omigosh! (1)

joeytsai (49613) | more than 13 years ago | (#253527)

Who would figure there would be impressive benchmarks on the Namesys page? ;)

In all fairness, though, I don't see any filesystem benchmarks done by anyone else... some good comparisons of all the new filesystems (not just ext3) would be pretty useful.

Unofficial patch (4)

chrysalis (50680) | more than 13 years ago | (#253528)

XFS is still an external patch, it's not included in the official kernel. And it seems that there is a delay between a new kernel release and a new XFS version for that kernel.
XFS 1.0 is against kernel 2.4.2 . Or 2.4.3, but SGI says it may be instable with this version.
But the current kernel is 2.4.4 (or 2.4.4-ac2) .
And 2.4.4 fixes important problems that previous kernels had. For instance, it fixes serious security flaws in Netfilter.
So, today, you can either run XFS, or get a fixed kernel. Not both.
This is why I'll stay with ReiserFS, until XFS get officially included in the kernel.

LILO Works Fine with ReiserFS... (1)

NetJunkie (56134) | more than 13 years ago | (#253529)

My notebook and desktops are 100% ReiserFS, and LILO boots them fine.

Yes. (3)

NetJunkie (56134) | more than 13 years ago | (#253530)

I used it on my companies web servers at my last place. We had millions of tiny files, and EXT2 wasn't cutting it. ReiserFS worked great.

And if you want someone better... SourceForge's FTP site is half on ReiserFS. So it works for them.

Install Disks? (3)

NetJunkie (56134) | more than 13 years ago | (#253531)

I used some of the install disks someone made to install Debian to a 100% ReiserFS system. Does anyone know of any disks to do this for XFS?

The Debian disks are on Freshmeat and work GREAT.

works with samba 2.2 acl's ? (2)

mbyte (65875) | more than 13 years ago | (#253535)

There are some known problems with earlier version of xfs (did try Test-1 myself, and it did not work :)

so did anyone try it yet ? does it work ?

Re:do nothing, successfully (2)

Emil Brink (69213) | more than 13 years ago | (#253536)

Avoiding any possible Microsoft-jokes, I think this [ncsu.edu] qualifies... Although I'm not 100% sure it's bigger, documentation-wise. Who knows, your favorite might be implemented as a symlink to this classic? ;^)

VMWare (1)

Phaser6047 (70775) | more than 13 years ago | (#253538)

Sorry for an off-topic comment.

Has anyone gotten VMWare working with XFS? I tried once and it wouldn't work.

Re:okay okay.... I'm not informed... (1)

altair1 (71744) | more than 13 years ago | (#253539)

> I believe it is the only ACL-enabled file system
> for Linux which has such utilities (unless you
> count AFS).

well, AFS [openafs.org] is really a network filesystem (kinda like NFS or SMB), rather than a "local" filesystem, like ext2, NTFS, reiserfs, etc. AFAIK XFS is among the later. An AFS server stores the files it holds in an ordinary local filesystem, like ext2 or xfs. Its ACLs are implemented in network daemons.

Re:Booting is tough (2)

botemout (76083) | more than 13 years ago | (#253540)

I was running 2.4.3 with reiser and knfsd patches for a week or so with NO problems. I first tried NFS over reiser 6 months ago (or so) and this is the FIRST TIME that I've had no problems.

I also, just today, compiled 2.4.4/w knfsd patches; seems fine too.

Re:Performance (2)

barneyfoo (80862) | more than 13 years ago | (#253541)

Anonymous Coward writes: upmoderating generic technical-sounding hooha delivered with a URL that you do not check is BAD.

Uhm, I just tried the link. It's not broken. It works. Maybe you should restart your proxy or something.

Re:Standardization (2)

barneyfoo (80862) | more than 13 years ago | (#253542)

hahaha

Seriously, anyone who is so uneducated to be confused or bewildered by having to choose from Gnome and KDE will not be fiddling around with filesystems anyway. They'll use whatever mandrake gives them on "beginner" or "automatic" install.

Re:Booting is tough (3)

barneyfoo (80862) | more than 13 years ago | (#253543)

Unlike Reiser, it currently works with NFS.

Yes this was an issue with Reiser, but they have had patches for it since 2.4.2 to work with NFS, and I beleive that full NFS support might be in 2.4.4 (not sure).

Re:Performance (4)

barneyfoo (80862) | more than 13 years ago | (#253544)

Minor quibble, I checked the reference, and that is reiserfs3.5 not 3.6 (the difference is that 3.5 is the linux2.2 reiser, and 3.6 is for linux2.4). When looking at 3.6 results, they appear marginally better, but your point still holds.

Create____203.88 / 171.95 = 1.19
Copy______411.67 / 384.59 = 1.07
Slinks____3.23 / 2.81 = 1.15
Read______1165.61 / 1291.76 = 0.90
Stats_____1.49 / 1.17 = 1.27
Rename____1.81 / 1.32 = 1.37
Delete____14.46 / 3.95 = 3.66


As an aside, it's pretty hard to get much faster than ext2 for this statistic, reading of bulk files greater than 10k less than 100k. You need to weigh what reiserfs gives you against what it could slow down. Reiserfs has truely awesome small file speed, and very nice tail packing.

Re:Performance (5)

barneyfoo (80862) | more than 13 years ago | (#253545)

I dont know how it compares to XFS. But go here [namesys.com] to see how ReiserFS compares to Ext2, Ext3. (Hint: it kicks its ass). Add in journaling and you have a killer combo. XFS is a little more industrial strength as opposed to general purpose. If you're streaming gigabyte files and processing them on the fly, I imagine XFS is the way to go.

Re:okay okay.... I'm not informed... (1)

merky1 (83978) | more than 13 years ago | (#253547)

Wouldn't you just be mirroring if you wrote user data to the log?

Re:Time tested (1)

adric (91323) | more than 13 years ago | (#253548)

So what is one of its strongest strengths over the other journaling fs's?

Time tested reliability.

On IRIX maybe. I'm pretty sure that the Linux port was more involved than a simply recompile, however. The test of time has barely started.
--

Re:journaling is nice, but how about a better RAID (2)

sheckard (91376) | more than 13 years ago | (#253549)

Software and hardware RAID support is already in the kernel and in use. LVM supports data striping if you don't want to go the full RAID route.

I don't see how things can possibly get much better.

Re:XFS (4)

sheckard (91376) | more than 13 years ago | (#253550)

ext3 is a hack to add journaling to ext2. An ext3 partition is backwards-compatible with ext2, so in a worst-case scenerio you could just mount it as ext2 and lose nothing but journaling. However, the support right now is 2.2 only, and personally, I don't think it's such a great idea to maintain backwards compatibility when so many underlying things change. This will only lock us into any bad compromises that were made in the design of ext2/3.

Re:okay okay.... I'm not informed... (5)

sheckard (91376) | more than 13 years ago | (#253551)

Well, the biggest difference is that XFS is proven and Reiser isn't yet. XFS has been the IRIX filesystem for something like 6 years now, and the on-disk filesystem format does not change between revisions, even during the development stage. You can even mount an IRIX disk under linux and read and write normally. The only thing in development in XFS were the userland and kernel-space tools. Compare that the Reiser where things tend to change a fair bit much.

Re:journaling is nice, but how about a better RAID (2)

jemfinch (94833) | more than 13 years ago | (#253552)

Um, 100baseT is 100 megabits per second. That's 12.5 megabytes per second. Even a "shitty ide hard drive" can saturate that.

Jeremy
--

Re:okay okay.... I'm not informed... (3)

bmajik (96670) | more than 13 years ago | (#253555)

Well, thats not _entirely_ true :) There was one absolutley devastating patch in the IRIX 6.2 time frame where 6.2 boot media couldn't boot machines that had the XFS patch applied to it.

That sucked :)

But i agree with you in general: XFS rocks. We were one of the first XFS customers on irix 5.3, and it didn't rock quite as much back then, but by the time irix 6.2 shipped it was pretty fantastic :)

I remember reading a post in comp.sys.sgi.{something} from one of the SGI guys... to the effect of "we have XFS doing sustained write performance of 2gb / second here in the lab"

That rules. :)

Re:Performance (3)

bmajik (96670) | more than 13 years ago | (#253556)

its meant to be a hi perf filesystem, from the start.

I mentioned this in another post, but SGI claimed internally to have it sustaining 2gb/sec of _write_ performance across a suitably large number of spindles.

Also, one thing i dont see people mentioning is XFS's support for GRIO (guarnateed rate I/O). No linux filesystem has that, and the linux kernel plumbing to support it i think is SGI contributed (if its on xfs for linux yet, i can't recall).

The idea of grio is an app says ahead of time "i need this much disk performance - figure it out", and the OS will say "yes, i can hook you up" or "sorry, throw more money at the problem".

Re:Booting (4)

rgmoore (133276) | more than 13 years ago | (#253560)

ReiserFS really shines with lots of small files. (your mp3 collection for example)

Since when do mp3s count as small files? Most of the interesting ones are several MB in size- much larger than a typical block size- so the extent to which ReiserFS would actually help is minimal. Where something like ReiserFS would be really helpful is in dealing with directories like /etc and /dev that are full of a large number of very small files. It might also be useful for /var, as ISTR that it has some anti-fragmentation aspects to it that would help with the rapidly changing data there.

Soon (1)

Ka0s (134504) | more than 13 years ago | (#253561)

From a debian planet article [debianplanet.org] :

The third in as many prominent efforts into releasing ReiserFS Debian Install Disks has been made by Zoltan Kraus. Though Zoltan has improved on his predecessor, John H. Robinson, IV's previous work substantially. Most notably Zoltan's disk are using 2.2.19 and ReiserFS 3.5.32 accompanied by the latest reiserfsprogs. His disks are at http://debianboot.digitaltux.com/.

They are also mirrored at http://www.markybob.com/zoltan/2.2disks In an email from him, he claims that "They have been tested and work perfectly on both desktops and laptops." Other patches that have also been included in the disk set are: Raid Patch 0.9, Raid1 ReadBalance, Hedrick's IDE Backport, Solar Designer's Secure Linux Patch, among other miscellaneous performance related patches.

In what could be a coup for Zoltan, he may become one of the first people to release a 2.4.x Debian install disk for public consumption as well as a set of XFS Debian Install disks which will be keenly sought after by many cutting edge Debian users. "I plan to make a set of XFS disks when they bump up their CVS to kernel 2.4.3 and a set of ReiserFS 2.4.3 disks when I have time to debug it." Seeing that 2.4.3 is out now, be on the lookup in the next few weeks.


Maybe he was waiting for XFS 1.0 - should be real soon now at any rate.

Re:Booting is tough (4)

Srin Tuar (147269) | more than 13 years ago | (#253562)

Itll work with LILO installed in the MBR. But if you want LILO in your root partition it wont work. Mostly this is due to the fact that SGI wishes XFS to be disk-compatible across systems.

Its probably still a way to go until its well integrated with the distributions, but I think this FS has potential. Unlike Reiser, it currently works with NFS.

I guess its a race to see which of these will ultimately become the common denominator FS for linux. Reiser currently has the lead, due to Suse and being in the kernel.

Mime types built into the file system? (1)

lightspawn (155347) | more than 13 years ago | (#253563)

Can anybody who's used these new FSs can comment on whether they have the file's mime type as a 'field'? I find this feature absolutely essential for stopping the 'web server has to guess a mime type, web browser tries to guess a mime type, file managers try to guess too...'. Ugh! And don't tell me about magic numbers.

A BeOS-wielding friend informs me it does that right, but I haven't had personal experience with it for more than a few minutes.

A new pop craze? (4)

The Night Watchman (170430) | more than 13 years ago | (#253567)

Yes, finally! Vince McMahon has come through to give us XFS: the eXtreme File System! Complete with new rules and directory structures, this will appeal to even the most hard-core file system fans. Under the new rules, all crosslinked files WILL be deleted on the spot, multiple programs attempting to write to the same block will be penalized for thirty million clock cycles, and all deletions are FINAL. And just check out the i-nodes on the cheerleaders. I think you'll agree this will be the new pop phenomenon.

Oh. Wait. Journaling file system? oops... never mind.

/* Steve */

Re:my exp with reiser (1)

SnapperHead (178050) | more than 13 years ago | (#253569)

Thats pretty odd. I have a Mandrake 7.2 install using rfs, when I upgraded to Mandrake 8.0. I didn't have to reformat or anything like that. Worked like a charm.

But, on the other hand. I tried recompleing the kernel on my laptop (Mandrake 7.2, rfs) from the stock 2.2 kernel -> 2.4.3. I never did get it to boot, after recomplieing a few times, I gave up. I had more important things to do.

On my workstation, I can switch from 2.2 and 2.4 only by selecting it at lilo. No changes are required.


until (succeed) try { again(); }

okay okay.... I'm not informed... (3)

Sir_Real (179104) | more than 13 years ago | (#253571)

What's the big diff (pun intended) between Reiser and XFS? Which is better? (I realize that this may start a holywar, but I want the brief synopsis and analysis since I'm not a sysadmin.)
Thanks

Re:Criteria how to choose file systems? (5)

Alien54 (180860) | more than 13 years ago | (#253573)

Since some file systems fits some purposes better than other file systems, and other file systems fits other purposes better than some file systems, what criterias do you have to consider when selecting a file system from another?

Some basic info and a couple of links for folks:

  • file system - basic defition -the general name given to the logical structures and software routines used to control access to the storage on a hard disk system. Operating systems use different ways of organizing and controlling access to data on the hard disk, and this choice is basically independent of the specific hardware being used--the same hard disk can be arranged in many different ways, and even multiple ways in different areas of the same disk.

  • Journaled file system - Basic definition (as seen here [internet.com] )

    A file system in which the hard disk maintains data integrity in the event of a system crash or if the system is otherwise halted abnormally. The journaled file system (JFS) maintains a log, or journal, of what activity has taken place in the main data areas of the disk; if a crash occurs, any lost data can be recreated because updates to the metadata in directories and bit maps have been written to a serial log. The JFS not only returns the data to the pre-crash configuration but also recovers unsaved data and stores it in the location it would have been stored in if the system had not been unexpectedly interrupted.

  • IBMs JFS webpage [ibm.com] on their system, along with links for for downloads and turtorials online,etc

There is an awfull lot of info at the SGI site [sgi.com] . Just poke around.

As far as the question about how to choose file systems, that is often a matter of what the OS will let you get away with, and your needs. Using FAT 16 is recommended if you need to maintain compatibility with MSDOS, for example. Usually, this is something like if you have a multi boot scenario, and which OSen can mount which partitions with which partitions. MS is notoriously picky in this regard, with a "My way or the Highway approach". For example, if you have a single hard drive hooked up to your computer for configuration purposes, You cannot just create anextended partition unless that drive is a salve with another master. If you want to create just an extended partition it will not permit, and tell you that you can only create a primary dos partition instead.

So you Live and you Learn

Check out the Vinny the Vampire [eplugz.com] comic strip

Re:Performance (4)

fatphil (181876) | more than 13 years ago | (#253575)

Be wary of statistics...

For example, picked pretty much at random from the mongo results, Linux-2.4.2 Ext2 vs. ReiserFS-3.6:

parameters:
files=15168
base_size=10000
bytes
dirs=86

Create 203.88 / 187.01 = 1.09
Copy 411.67 / 411.28 = 1.00
Slinks 3.23 / 2.99 = 1.08
Read 1165.61 / 1325.27 = 0.88
Stats 1.49 / 1.48 = 1.01
Rename 1.81 / 1.30 = 1.39
Delete 14.46 / 5.64 = 2.56

So the total time of the test is 1802.15 / 1934.97
= 0.93. (i.e. Reiser is 7% slower performing the whole test.)

I don't care if they make the thing that takes a tenth of a millisecond twice as fast, it's the reading of the bulk of the file that takes the most time, and for that part, Reiser is slower.

However, each individual has got to look at what is most important for them, for me it's 99% file read time on medium to large files (30K source code, 200K log files, that kind of thing), and judge accordingly.

FatPhil
--

Time tested (4)

Thax (189063) | more than 13 years ago | (#253576)

One of the big plusses that XFS has over Reiser and ext3 is that it is time tested. It has been used on IRIX machines for a long time and is rock solid on those platforms, its been running under linux for a long time in a beta stage and now SGI appears to believe that its as robust and useable in production environments.

So what is one of its strongest strengths over the other journaling fs's?

Time tested reliability.

Reiser... (1)

A**Grind (191634) | more than 13 years ago | (#253577)

Is anyone using this in a production environment yet? I've toyed with the idea but all machines that I have tried it on end up with corrupted data...

Re:okay okay.... I'm not informed... (5)

SuperBug (200913) | more than 13 years ago | (#253579)

XFS has a few things that Reiser doesn't. One of the biggest things I can think of is Syncrhonous/Asynchronous IO, Modifiable Journal sizes(at create time), and the journals are entirely different. So, while reiser is WAY kewl, XFS offers more in the way of the capabilities Veritas offers. This I like because it's more like having a FREE version of veritas. Most people don't use all the capabilities of that slow bloated beast anyway, so something which still journals like a champ, and a bit faster overall than reiserfs, is ok by me. I'd been using ReiserFS for several months now, and am running it on my oracle server. I recently reinstalled with the RedHat XFS install cd that SGI put out and I must say it is definitely faster in many respects than reiser. Also, the error instance boot time startup log checks are almost 'un-noticeable'. This I feel is a much needed change compared to that of reiserfs or ext3. I still await Tux2 However, to hopefully be an inline replacement to ext2. But for now, my systems will use both Reiserfs, and XFS for sure! Nothing but goodness so far!

XFS (2)

pcidevel (207951) | more than 13 years ago | (#253588)

Well.. as long as it's not affiliated with the XFL I guess it will be okay! Seriously, how does this file system compare to ext3? Should I just wait? :)

JFFS and JFFS2 (1)

BlowCat (216402) | more than 13 years ago | (#253589)

You have missed JFFS and JFFS2 - journaling flash filesystems. Both are in the kernel (2.4.4-ac2).

do nothing, successfully (5)

mojo-raisin (223411) | more than 13 years ago | (#253592)

My favorite utility [sgi.com] of the xfs distribution. Where else could you find so much joy about a program that does nothing?

Re:Booting (4)

Xibby (232218) | more than 13 years ago | (#253594)

You can boot off of ReiserFS just fine with lilo. Ealier versions or lilo and Reiser required that you used the --notail option when mounting the root partition. Since this negates the usefulness of reiser, it was recomended that you lop off a /boot partition and mount that with the notail option. I belive newer versions of lilo don't need the notail option, but the ReiserFS docs haven't been updated.

ReiserFS really shines with lots of small files. (your mp3 collection for example) You'll generally reclaim some space on your drive when you go from ext2 or vfat to reiser.

XFS is good when high performance is needed when dealing with large file systems (terabytes) and large files (1,2 gb files.) For a standard home user, it's overkill. :) But many slashdot readers like overkill...

Re:okay okay.... I'm not informed... (1)

sales_worldwide (244279) | more than 13 years ago | (#253597)

The difference is that Reiser is NOT a journaling filesystem (well, not any more that, say, NT or BSD UFS filesystems are), since it only journals the meta data (filenames, directory names, permissions, timestamps etc.) This should be a bare minimum absolute requirement for a filesystem in any case. Reiser is simply bringing linux up to the same state as NT or BSD, in that a system crash will leave the filesystem in a sensible state even if a bit of data is lost (by sensible we mean that directory and file nodes all match or are at least fixable - with linux in the current state it is all too easy to get the fielsystem in a seriously bad state)

XFS however is a true journaling filesystem. The filesystem will not take an hour to fsck 100Gig+ disks. It will take a minute or two. This is because the filesystem data is journaled (as well as the meta data).

However, I still am puzzled as to how the hell XFS (or even reiser) can get around the fact that linux doesn't have an raw devices or a working fsync call. How can the filesystem code possibly know when data is on the disk when the kernel is caching it (and lies wrt to stuff like fsync()s?) Answers on a postcard please.

Re:pondering (5)

cmowire (254489) | more than 13 years ago | (#253599)

If you watch SGI's strategy, they seem to be moving towards that direction. They are keeping Irix around primarily because Linux isn't ready and there aren't any good 64-bit processors out that fit with their business model other than a MIPS, right now.

I mean, think about it. Why bother writing all of the kernels and utilities when you can have the hackers of the world pick up the slack? SGI can't put as many developers on Irix as MS can put on Windoze. So they are developing Irix only for the MIPS machines and keeping Linux for their Intel machines.

And the strategy is pretty evident. They have been very supportive of good OpenGL under Linux. They have XFS, clustering software, etc. All of the Irix advantages are getting ported over.

The problem is that they haven't been able to move over to the Intel platform properly. Their first attempt was a fiasco. The Onyx 3000 series was designed to be a transitional system. It can work with either a MIPS processor or an Itanium. But the Itanium delays are making that hard. And, unlike the desktop workstations, you can't stuff a Pentium 4 in a Onyx because you need 64 bit addressing to make their NUMA architecture work -- each processor gets a piece of the address space. With a 512 processor Onyx 3000, that makes 8 megs of RAM per processor. So Intel is holding up SGI's full migration to Linux.

Now, as far as the stability of SGI, I'm not entirely sure. They are still bleeding money, and at a faster rate than last year, too. Given the downturn in the tech economy, they are going to be hit with it, too. It's very shakey.

Re:Standardization (1)

stanfinger (258588) | more than 13 years ago | (#253600)

And that will be?

I think that part of the problem he's addressing is that there may be controversy over what SHOULD be the "automatic" or "beginner" install's fs.

journaling is nice, but how about a better RAID? (1)

typical geek (261980) | more than 13 years ago | (#253601)

A journaling file system is grea,t but Linux needs better RAID support, maybe even data striping.

Where I'm coming from:

I just upgraded my home network to 100baseT. Now, how the hell am I going to saturate a 100Mbps link with a shitty IDE hard drive, or even a faster SCSI?

I need some way to stream my DIVX:) at 100Mbps, so I can transfer a movie to my set side box in 10 seconds.

pondering (4)

deran9ed (300694) | more than 13 years ago | (#253603)


I wonder if folks over at SGI plan on dropping Irix in the near future for Linux entirely. As it stands right now the majority of their hardware run Linux, and the last version of Irix released was to mainly fix bugs.

Its a shame that SGI has done pretty poor the past few years, when they're such kick ass machines, and personally I think they should kick the marketing teams asses.

I know previously they've used a customized version of Windows exclusively on their 320/540 servers, I guess they changed em all around to avoid fireselling them at crackhead prices. Maybe someday I'll see a BSD running on an Irix machine to see how it would run in comparison to Linux (don't bother to troll this post this is not an OS war-penis-envious-linux-vs-bsd-post) as far as benchmarking is concerned. As for XFS support I though it was supported for reading and not writing? Oh well I don't use Linux anymore ;)

Re:journaling is nice, but how about a better RAID (1)

shorti9 (307602) | more than 13 years ago | (#253604)

perhaps i'm just shining with ignorance here, but does DiVX not stream?

personally, i'm planning on using MPEG2 over 100Mb as a stream, if/when i bother to build a set-top box. on my sony dvd player, it has a nice "bandwidth monitor", which tops out at about 10Mbps.

Standardization (1)

andrewscraig (319163) | more than 13 years ago | (#253609)

While ordinarily, I think that the freedom-of-choice with Open Source Software is a good idea, in cases so close to the "core" OS (e.g. filesystems or GUI's) it might be better to have a "standard" one.
We've lived for so long with primarily ext2 - but now we have the choice of XFS, reiserfs, and ext3...which could result in confusion.
We are already seeing this happen with the Gnome/KDE flame-wars - lets hope it doesn't happen with filesystems. Hopefully there'll be a merge of the different filesystems to take the best from each (at least this time they are all issued under the same licence!)

--
Andrew

Re:Standardization (1)

andrewscraig (319163) | more than 13 years ago | (#253610)

I do remember that ext2 was not the only fs that Linux uses (hence the '2' bit :-) ) -- in fact I'm very glad that it supports multiple fs's (the sooner it supports writing to W2K NTFS, the better...(I forgot to make a communal vfat storage area last time I did a re-install)...
What I was concerned over was that by fragmenting the filesystem development, there is some obvious duplication of work involved (although much less given the common licence among them).
However, from reading the other posts here I see that in this case, perhaps continuing development on the other filesystems might be a good plan.

--
Andrew

Re:Booting (1)

Chakat (320875) | more than 13 years ago | (#253611)

I don't know about the rest of the loaders, as my experience is more with x86 boxes, but the newer revs of LILO support booting from a reiser root partition. However, the problems remains as to how to handle a new partition type. I don't know about what other people do, but the what I do on my Linux boxes is to create a ~10MB ext2 partition on the first available sectors as a /boot partition. You really don't need to worry about corruption, because the only real time you need to read/write to it is when you're booting or upgrading the kernel; the rest of the time it's idle.

An added benefit of placing the /boot partition is you can boot your hard drive off of any box without having to worry about broken bioses, etc, which can't handle past certain "magic" disk setups.

Re:okay okay.... I'm not informed... (5)

pat_1729 (416011) | more than 13 years ago | (#253614)

XFS has ACLs, unlike ReiserFS and ext3 (last time I checked).

Also, XFS comes with xfsdump and xfsrestore, which can back up and restore the ACLs. I believe it is the only ACL-enabled file system for Linux which has such utilities (unless you count AFS).

So for a production environment where you want ACLs, XFS is the only choice right now. And it seems likely to remain so for a while.

Also, Samba 2.2 has built-in integration with XFS ACLs, making Linux+XFS+Samba a very interesting option for replacing NT file servers.

Re:Booting (1)

dinivin (444905) | more than 13 years ago | (#253615)


You know wrong... Reiser most certainly supports root file systems. Even /boot filesystems.

Dinivin

Re:The Current Tally... (1)

Professor Calculus (447783) | more than 13 years ago | (#253616)

It think you are confusing NTFS with FAT. NTFS is a full journalling filesystem complete with large volume support, file permissions and all that. While it is not very portable or particularly fast at anything, it is stable and works very well for desktop systems. FAT, on the other hand, is so ancient it should never be used for any system other than in a museum display.

There is a big difference, and NTFS is a force to be reckoned with, although it pales in comparison with XFS.

Re:okay okay.... I'm not informed... (3)

Professor Calculus (447783) | more than 13 years ago | (#253617)

ReiserFS is a unique(AFAIK) new design intended to boost performance for small file accesses. It is highly optimized not only to reduce the number of seeks necessary to get to a small file but also to continually re-arrange the data for faster access using very advanced(and kinda slow) algorithms. It's approach is to use spare disk and CPU time to decrease file access time. It is not focused on large files and does little optimization for them.

XFS, on the other hand, was designed with today's multimedia systems in mind. It supports systems in the millions of terabytes range, and has highly scalable, optimized data structures for metadata and journaling. Thus it is able to run on multiple CPU and RAID servers, with the intention to actually be serving multiple raw video or other high bandwidth streams. It has a special subsystem that handles Guaranteed Rate I/O, both soft(error checked) and hard(will deliver bad data if needed) data rate guarantees. I'm not sure if the GRIO stuff is fully supported in linux right now, but it requires special system calls which linux software obviously doen't have support for yet anyway.

ReiserFS and XFS are both VERY cool, but they address completely different areas of file system optimixation, desktops and multimedia servers. Use the right tool for the right task, etc. means that XFS is the only choice for high bandwidth linux data servers at this point. That's why this is a big deal.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>