XFS merged in Linux 2.5

Comparison? by FyRE666 · 2002-09-17 03:32 · Score: 3, Interesting

Does anyone have a link to any comparisons of all these journaling filesystems, showing their strengths and weaknesses? Why shouldn't I just stick with ext3 for everything?

--
Code, Hardware, stuff like that.

Cool by mortis_aeturnus · 2002-09-17 03:32 · Score: 2, Interesting

From linux-2.6 on I don't have to repatch the kernel source with that sgi.com XFS patch everytime a new kernel comes out. BTW, I still have trouble getting XFS to work on linux-2.4.19 because sgi won't update their stable XFS patch from 2.4.18.

Not just journaling by Anonymous Coward · 2002-09-17 03:34 · Score: 5, Interesting

As I understand it, XFS also offers things like extended attributes. However, I have been told that the Linux VFS does not offer any way to read or write the attribute information?

Is this correct? Will the VFS also be extended so that you can make use of extended attributes in XFS?

Re:Not just journaling by publius · 2002-09-17 03:57 · Score: 5, Interesting

I read them, write them and delete them all the time using the attr family of commands. 64K limitation on the current value size but that's not so bad, and in the future it will be the (I think) 512K that Irix has. When you begin to think of all the cool things you can do with that, it becomes very interesting...
Re:Not just journaling by Anonymous Coward · 2002-09-17 04:02 · Score: 1, Interesting

Yes, attributes are certainly cool. Both BFS and AFS (AtheOS/Syllable) use attributes.

I'm wondering about Linux supporting them (At least nominaly, with XFS) as at the moment, tools that understand attributes are a little thin on the ground. tar, for example, does not understand attributes. Nor do the usual GNU fileutils. Linux support could hopefully mean broader and standardised support in general, which would make our job a little easier.
Re:Not just journaling by IamTheRealMike · 2002-09-17 04:18 · Score: 5, Interesting

Is this correct? Will the VFS also be extended so that you can make use of extended attributes in XFS?
Cooler, if I read the tea leaves right. I believe some time ago now there was a thread on lkml about whether it'd be possible to have files as also directories (and vice-versa). The reasoning behind this was simple: we want flexible filing system attributes, but not at the expense of API bloat. You want ACLs? That'll be another API then. Extended Attributes? Another API. What, you want heirarchical extended attributes too? Well you've just created another version of the filing system API haven't you.
The theory goes (and Hans Reiser, top guy, explains it much better than I can) that by altering one of the rules of the filing system, we can get lots more power and expressiveness without having to invent lots of new APIs. Let's say you want to find out the owner of file foo. You can just read /home/user/foo/owner. You can edit ACLs by doing similar operations. Now you can have something more powerful than extended attributes, but you can also manipulate that data using the standard command line tools too! Coupled with a more powerful version of locate, you can have very interesting searching and indexing facilities.
This has implications beyond just string attributes. Now throw in plugins, so for instance the FS layer interprets JPEGs and adds extra attributes. Now you can read the colour depth of an image by doing "cat photo.jpg/colour_depth" or whatever. You can get the raw, uncompressed version of the file by doing "cp photo.jpg/raw > photo.raw". Noticed something yet? You no longer need a new API for reading JPEG data, because you are reusing the filing system API.
But the FS is not a powerful enough concept, I hear you cry! Have no fear, for with new storage mechanisms comes new syntax too, to allow for BeFS style live queries. If you want more info, you should really read up on this stuff at Reisers site.
That's why ReiserFS is so good at small files as well as large files. Have you ever wondered why that is? It's not just a quirk of its design, it was very deliberate. One day, Hans wants to see us store as much information as possible in a souped up version of the filing system, so reducing interfaces and increasing interconnectedness. Or something. It sounds cool anyway :) That's one thing that RFS has that the other *FSs don't - the ReiserFS team has vision.
Re:Not just journaling by goga · 2002-09-17 04:33 · Score: 2, Interesting

This all sounds very Plan 9-ish. (Not that you can read files as directories in Plan 9.)
Re:Not just journaling by 1010011010 · 2002-09-17 04:57 · Score: 3, Interesting

How do I use these named streams for a directory? To re-use your example, can I:

$ cat $HOME/owner

and get my username? Or will it be looking for a file named "owner" in $HOME?

--
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.

Silly question by Mr_Silver · 2002-09-17 03:41 · Score: 5, Interesting

This is a silly question but ...

When I install Linux, and it comes to anything to do with filesystems, I just go with whatever default it gives me.

I suspect I'm not exactly alone.

So ... what compelling reason is there for me to use any other filesystem? Being more stable or better with data loss is nice, but considering I've only ever had this problem once, doesn't mean that i'll leap up and down going "oo oo! got to have blahFS!" any time soon.

To give you an example, FAT16 to FAT32 was the fact you could have larger partitions. FAT32 to NTFS was because of permissions and security.

But whatever we have now (can't remember, i barely look) to XFS? What *compelling* absolutely-must-have reason do I have to go change from whatever my installer suggests putting on for me?

Or should I just stick with what the installer suggests from now until eternity?

--
Avantslash - View Slashdot cleanly on your mobile phone.

Re:Silly question by kelv · 2002-09-17 03:48 · Score: 2, Interesting

As a desktop user you might be able to get away with any old filesystem......

However, if you have a server that has to have high performance and has data that you *really* care about then one of ReiserFS, XFS, EXT3, etc... becomes a *really* good idea.
Re:Silly question by Jeremy+Allison+-+Sam · 2002-09-17 06:36 · Score: 5, Interesting

POSIX ACLs aren't much more complex than
standard UNIX permissions and allow you to do
the 2 common cases :

1). Group finance has access + user Jill
2). Group finance has acces but not user fred.

But then again I wrote the Samba POSIX ACL
code so I'm biased :-).

Windows ACLs are a complete *nightmare* in
comparison. I still don't understand why Sun
added an incompatible varient of Windows ACLs
to NFSv4 (ie. it's close, but not the same as
the real Windows ACLs. The problem is they based
the spec. on the Microsoft documentation of how
the ACLs work. Big mistake.... :-).

Regards,

Jeremy Allison,
Samba Team.

Questions... by pubjames · 2002-09-17 03:43 · Score: 3, Interesting

When is Linux 2.6 likely to be released? I know that there is no fixed date, but what are the criteria?

My second question... Does it really matter when the 'official' release comes out, when distribution makers "roll-their-own" anyway?

Sorry if these sound like dumb questions to some of you, but I'd be interested to find out.

Re:XFS FAQ by Anonymous Coward · 2002-09-17 03:44 · Score: 1, Interesting

One of the big advantages is that this means you can now have XFS alongside other major kernel patches, once 2.6 is out. A thread had come up a while back with someone wanting to run XFS with openMosix, this virtually guarantees that it will work in the future.

Re:My understanding by 4of12 · 2002-09-17 03:51 · Score: 4, Interesting

xfs:
* tweaked for streaming large files to/from disk
-- probably best at sequential reads/writes.

Hm...would that imply that XFS would be say a really good candidate FS for building video streaming devices?

Seems like it might fit well from the perspective of:

high speed read write (good enough for 1080i?)
quick reboots due to journaling (essential for consumer electronics devices)
don't have a cow if there are a few bit errors in the stream

--
"Provided by the management for your protection."

2.6 kernel goodies by 0x0d0a · 2002-09-17 03:55 · Score: 4, Interesting

2.6 has got me more excited than recent minor releases. Some of the things that look cool:

* ALSA support. ALSA is a pain to keep patching your kernel with every redownload. ALSA is a Good Thing, if a pain in the butt to configure. My guess is that there will be decent front ends on top of the thing when distros start shipping 2.6.
* Batch priority/boosted effect of nice levels. I've always felt that "nicing" something didn't have enough effect -- nicing something by one level is almost unnoticeable. 2.6 boosts this change. It also introduces batch priority, where a process gets *no* CPU time if there is *any* non-batch process in the runnable queue. Very sexy.
* Low, low latency. Just as 2.4 emphasized good multiproc support, 2.6 is emphasizing low latency. Preemptive kernel, lots of disabled-interrupt time being reduced (especially the godawful framebuffer console), etc, etc. This is top-notch for both I/O performance and multimedia. Linux kernel 2.6 is supposed to beat any current release of Windows in audio latency when released.

The only thing that I really wish Linux had was a prioritized disk scheduler. Linux can prioritize network traffic. It can prioritize processes. It just can't do the same with disk I/O. This is a shame, since I want my MP3 player not to skip when reading MP3s/paging, followed by X getting next highest priority when paging (so that the UI doesn't freeze up for long when paging something back in), and Linux just doesn't yet have the functionality. Currently, you can have a nice 20 process that's busy untarring a large tarball...and all your paged out processes will be blocked, waiting for this stupid tarball to finish.

--
May we never see th

Re:2.6 kernel goodies by 0x0d0a · 2002-09-17 04:27 · Score: 3, Interesting

The skipping in your mp3 player has nothing to do with disk i/o. It has to do with scheduling latency.

Not true. I've done quite a bit of poking around this issue. I have plenty of spare CPU time, and I'm not using a sound server or similar. The problem comes when reading an mp3 from disk (and no, this is not a "DMA/umasked interrupts" is not on issue) and other *heavy* sequential disk i/o is being done by another piece of software (because of the amount of data, tar xzvf is frequently the culprit). Linux heavily weights disk scheduling towards overall performance, not fairness. Besides, this isn't mp3-specific -- other software does it too. Try cat /dev/zero > foo and then trying to ls a directory. Extremely long delay. Heck, try doing said operation when playing an mp3 and you'll see the skipping I'm talking about. Seriously, try it -- it takes about ten seconds to try.

I remember seeing benchmarks of various Windows audio latencies and Linux latencys, and at least the low-latency people had Linux at least a couple of ms below Windows. I wasn't aware that only some of these patches were going in, though, so that could be the difference between what we're talking about.

--
May we never see th
Re:2.6 kernel goodies by Adnans · 2002-09-17 06:49 · Score: 3, Interesting

The problem comes when reading an mp3 from disk (and no, this is not a "DMA/umasked interrupts" is not on issue) and other *heavy* sequential disk i/o is being done by another piece of software (because of the amount of data, tar xzvf is frequently the culprit).

The skipping is caused by scheduling latency, as Paul suggests. I have written an mp3 player for Linux (see URL) and it only really skips when the audio output thread is not scheduled in time to satisfy the soundcard's needs. I.e. the Linux scheduler needs to make sure that whenever the audio thread wants to fill the soundcard buffers it must get the highest priority to do so. For example if you are using a soundcard buffer that is split into 2 fragments of 1024 bytes each that means that the audio thread needs to be scheduled every 6ms, 3ms for 512 byte fragments (44KHZ stereo, 16bit output). Even when your soundcard buffer size is 50 or 100ms deep you can very easily cause skipping if your audio thread is not scheduled for 100ms or longer. And this is pretty normal on a vanilla kernel for non-realtime scheduled processes. Think about it, your "cat > /dev/zero" has the same priority as your audio thread so they have equal rights to the CPU, however the audio thread has much stricter scheduling needs since you will get audio skips whenever it is scheduled too late (i.e. the soundcard buffers get depleted)

In short, the soundcard will be starved of ready to play PCM data long before the decoder will be starved of MP3 encoded data (from disk). In the end it doesn't really matter because your music still skips, but it is important to identify exactly why it's skipping.

-adnans

--
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds

My experience with XFS by chrysalis · 2002-09-17 03:58 · Score: 5, Interesting

I've been running Gentoo Linux for some times with XFS. Here's my experience with this filesystem :

- It's extremely reliable. Filesystems never got corrupted, even after a lot of ugly reboots.

- Recoveries after a crash are really fast. Almost immedate, better than ext3 and reiserfs.

- Every needed tool is available to resize filesystems, check filesystems, analyze filesystems and backup/restore filesystems.

- _BUT_ there's something strange. Basically during disk I/O, the whole system is unresponsive. While I'm compiling something, KDE becomes slow, playing videos is not smooth at all, etc. Just as if it didn't scale at all for concurrent disk access. So I finally switched back to ReiserFS just because of this. Maybe the 2.5.x series of kernel behaves differently.

--
{{.sig}}

Soft Updates in Linux? by Dan+Ost · 2002-09-17 04:09 · Score: 2, Interesting

I've been reading about the differences between
using journals and using soft updates and have
decided that soft updates is the cleaner approach.

Can anyone explain to me why the Linux community
is so enthralled with the concept of journaling
file systems while the BSD community has quietly
but unanimously embraced soft updates?

--

*sigh* back to work...

Why is kernel-image so big? by Thagg · 2002-09-17 05:32 · Score: 3, Interesting

I recently installed Linux-XFS on one of my computers here, as I was having problems with the kjournald process under ext3 taking extremely unreasonable amounts of time -- and I had had wonderful experiences with XFS on our SGIs -- it's always been solid and fast. Various reviewers of ext3 had complained about the existence of kjournald -- disputing the need for a user-code daemon.

Several places it is mentioned, though, that the kernel image of XFS is very large, so much that you can't really fit it onto a floppy (although people over-format their floppies to get 1.8 MB or so onto them, and then the kernel might just barely fit.)

I can't understand why any filesystem should be so big -- it seems that the code to run the filesystem is almost as big as the rest of Linux put together. How can this be? Is it really all code? What could that code possibly be doing?

I studied XFS fairly extensively after I had to repair a disk that had 1 of its 23 heads fail. From the remaining 22/23rd of the disk I managed to recover almost every file and directory, by writing my own XFS filesystem interpretation code. The on-disk organization of the filesystem is fairly simple and straightforward, I can't imagine where the hundreds of K of code is going.

I won't be shocked if the answer does lie in that kjournald daemon -- that XFS is bigger than ext3 because ext3 puts most of the bloat into a user-mode daemon instead of the kernel.

thad

--
I love Mondays. On a Monday, anything is possible.

Related question by Quixote · 2002-09-17 06:01 · Score: 3, Interesting

XFS has a file size limit of 32TB (or so, I think), with a _filesystem_ limit in the EBs. But, I've heard that the Linux VFS layer has a max file size limit of 1TB. Is it possible to create files > 1TB on a Linux+XFS box ? Unfortunately, I don't have the resources to try it out just yet... :-)

Transactions? by ndecker · 2002-09-17 06:38 · Score: 2, Interesting

Is there any FS/API that allows ACID style transactions for applications on filesystems?

This way it would allow cool stuff like garanteed data consistency or rollback.

Imagine

$ begin_trans
$ rm -rf /
$ rollback_trans

22 of 271 comments (clear)