I am glad to see Marcelo relenting on his hard line position and allowing more patches into the 2.4 line, as I know it will be my main kernel until a couple of patch releases have come out for 2.6…
ReiserFS here too and Open Office works fine. I really don’t understand how a filesystem can affect an office app at all. The workings of it all all abstracted away long before the api for the office app to use the filesystem.
There’s nothing more frustrating than wanting to upgrade the kernel of an XFS system only to find that though you’ve downloaded the kernel sources you can’t get the XFS patch because oss.sgi.com is down.
XFS does, which ext3 doesn’t? I can understand “fully multithreaded” and more scalable, but I don’t know what is “extended attributes” and “extent based”. Also variable block size means block size changes at run time? Or you have to set it when you make the fs?
While not completely up on ext3, it has always seems like a kludge. It’s a standard table based fs with logging grafted onto the side. It seems to work well enough, but just seems odd. XFS, in contrast, was written from day one to be 64-bit and logging, so its design makes more sense.
As for comparison, the file and volume limits are ‘big enough’ for both (2TB for ext3 and 18TB for XFS), so that’s now moot. Speeds are similar for most cases (although XFS’s deletes and small file handling are on the slow side). Unless someone tells me I’m wrong, ext3 has to do an old, slow, fsck when it isn’t unmounted properly, whereas XFS’s fsck is never more than 1 second. That’s the biggest difference, I’d think.
As much as I love that XFS is now in 2.4, it *does* seem like an awfully big patch to put in the *stable* kernel. In the last year or so, the Linux kernel guys really seem to not worry about making large changes to the stable kernel, which is disconcerting. I’m thinking this and more notably the wholesale VM change around 2.4.10 are things to really worry about, since in the XFS case, it’ll be in the 2.6.0 kernel which should be out RSN.
I was thinking the same thing, I remember reading something not so long ago about the push of 2.6 and how 2.4 was about to be frozen for all accept maintenance patches. That informatioin must have been premature.
No, you can still use any file system you’re using today. It just means that XFS is an option. And BTW, you don’t have to use lilo if you use XFS. I’ve used grub with it before :] You just have to make sure your boot partition isn’t XFS or use the chainloader option.
As others have mentioned, XFS and GRUB do work together just fine. I think I even remember having an XFS boot partition once upon a time (I think I was installing Gentoo 1.0rc1 a couple years ago). GRUB worked, but savedefault didn’t.
I recommend GRUB to just about anyone. The best thing to do is make a 100MB ext2 partition as your first primary, and use that for GRUB. Use the native grub stuff when you can (Linux, Freebsd 4.x), and chainload what you can’t (Windows, Freebsd 5.x).
From SGI site: “Designed to scale to 9 million TB with current hardware supporting scalability to 8000 TB on IRIX. Linux-64, 2 TB Max File Size. Solaris and Windows NT undergoing scalability testing.”
Though it doesn’t have any thing to do with me in the near future, it is amusing.
Anyone knows what are “extended attributes” and “extent based”?
Since XFS as patch is quite a headache to apply together with other patches (say, GrSecurity) i for one am very happy that i’ll have the possibility to use 2.4.x vanilla together with other patches in the near future. Thanks!
(…) I really don’t understand how a filesystem can affect an office app at all.
Fom the README.html of my Linux.OO.org tar.gz:
« In versions lower than 3.6, the file system ReiserFS causes a problem as soon as the user ID is larger than 65535. The problem is that files temporarily saved by OpenOffice.org can no longer be removed by the program itself, but rather only by the system administrator (e.g. /tmp/OSL_PIPE_xxx ). The result is that OpenOffice.org cannot be started. The problem is in the ReiserFS file system and has been fixed in version 3.6 and higher. »
Now you can understand why. And yes, it’s weird.
In my case (Mandrake 9.0 and Slackware 9.1 uses a stable Reiser version = not the latest) it couldn’t even start the install properly.
_____________________
I like XFS and also JFS, the last (JFS) seems to make the start up faster and the disk noise is stranger when you listen to it (if you like to pay attention).
I also install with linux on software raid with 2 disks sometimes – RedHat and Mandrake work good on this was it last time with ~64k block size ? — to test differences, but if the FS isn’t on the kernel better not try it…
maybe 2.6 will have even more enhancements for soft raid XFS.
From what I can tell, XFS is a hybrid (like more fs, I believe), where is logs for awhile, then updates the disk structure (which is stored in extents).
I am glad to see Marcelo relenting on his hard line position and allowing more patches into the 2.4 line, as I know it will be my main kernel until a couple of patch releases have come out for 2.6…
whoops, typed in my pseudo email in the subject line…need more coffee… to early
I know they are maintained by different developers but will it be in the kernel on the 2.6 kernel version too ?
(can the added 2.4 code be inserted on the 2.6 “directly”).
(I’ve been using ext3 lately since OpenOffice 1.1 does not install on ReiserFS).
XFS has been in the 2.5/2.6 kernel for quite some time.
>(I’ve been using ext3 lately since OpenOffice 1.1 does not
> install on ReiserFS).
My Debian box at home is ReiserFS v3 and OpenOffice 1.1 works fine…
ReiserFS here too and Open Office works fine. I really don’t understand how a filesystem can affect an office app at all. The workings of it all all abstracted away long before the api for the office app to use the filesystem.
There’s nothing more frustrating than wanting to upgrade the kernel of an XFS system only to find that though you’ve downloaded the kernel sources you can’t get the XFS patch because oss.sgi.com is down.
XFS does, which ext3 doesn’t? I can understand “fully multithreaded” and more scalable, but I don’t know what is “extended attributes” and “extent based”. Also variable block size means block size changes at run time? Or you have to set it when you make the fs?
Better not let SCO find out
While not completely up on ext3, it has always seems like a kludge. It’s a standard table based fs with logging grafted onto the side. It seems to work well enough, but just seems odd. XFS, in contrast, was written from day one to be 64-bit and logging, so its design makes more sense.
As for comparison, the file and volume limits are ‘big enough’ for both (2TB for ext3 and 18TB for XFS), so that’s now moot. Speeds are similar for most cases (although XFS’s deletes and small file handling are on the slow side). Unless someone tells me I’m wrong, ext3 has to do an old, slow, fsck when it isn’t unmounted properly, whereas XFS’s fsck is never more than 1 second. That’s the biggest difference, I’d think.
As much as I love that XFS is now in 2.4, it *does* seem like an awfully big patch to put in the *stable* kernel. In the last year or so, the Linux kernel guys really seem to not worry about making large changes to the stable kernel, which is disconcerting. I’m thinking this and more notably the wholesale VM change around 2.4.10 are things to really worry about, since in the XFS case, it’ll be in the 2.6.0 kernel which should be out RSN.
Does this means I can’t use any other file system if I have kernel 2.4? I don’t like xfs because it forces me to use lilo.
I was thinking the same thing, I remember reading something not so long ago about the push of 2.6 and how 2.4 was about to be frozen for all accept maintenance patches. That informatioin must have been premature.
@arthur:
No, you can still use any file system you’re using today. It just means that XFS is an option. And BTW, you don’t have to use lilo if you use XFS. I’ve used grub with it before :] You just have to make sure your boot partition isn’t XFS or use the chainloader option.
No, you don’t have to use XFS. All this means is that if you want to use xfs, you don’t have to patch your kernel with a separate set of sources.
As others have mentioned, XFS and GRUB do work together just fine. I think I even remember having an XFS boot partition once upon a time (I think I was installing Gentoo 1.0rc1 a couple years ago). GRUB worked, but savedefault didn’t.
I recommend GRUB to just about anyone. The best thing to do is make a 100MB ext2 partition as your first primary, and use that for GRUB. Use the native grub stuff when you can (Linux, Freebsd 4.x), and chainload what you can’t (Windows, Freebsd 5.x).
Sorry! But XFS is designed to allow bigger files then 18TB.
Read: http://www.sgi.com/software/xfs/techinfo.html
cheers
SteveB
From SGI site: “Designed to scale to 9 million TB with current hardware supporting scalability to 8000 TB on IRIX. Linux-64, 2 TB Max File Size. Solaris and Windows NT undergoing scalability testing.”
Though it doesn’t have any thing to do with me in the near future, it is amusing.
Anyone knows what are “extended attributes” and “extent based”?
Since XFS as patch is quite a headache to apply together with other patches (say, GrSecurity) i for one am very happy that i’ll have the possibility to use 2.4.x vanilla together with other patches in the near future. Thanks!
> but I don’t know what is “extended attributes”
Extended attributes is the ability to associate name/value
pairs with a file. For example, access control lists are
implemented by the O/S adding an attribute to the file or
directory, which stores the control list data. So these
name/value pairs can be created and used by applications,
or by the operating system to “extend” the information
about files and directories on the filesystem.
> and “extent based”.
A method of allocating space for a file on the disk.
> Also variable block size means block size changes at run
> time? Or you have to set it when you make the fs?
You still have to set it when you create the filesystem,
XFS can support 512b up to 64Kb blocks sizes under IRIX,
there may be some limitations with Linux, I’m not sure.
There is more info at http://www.sgi.com/software/xfs.
Still waiting on Reiser4…
What I would like to see is an announcement that HFS/HFS+ is being merged into the 2.6 kernel. Kinda need it for my iPod.
(…) I really don’t understand how a filesystem can affect an office app at all.
Fom the README.html of my Linux.OO.org tar.gz:
« In versions lower than 3.6, the file system ReiserFS causes a problem as soon as the user ID is larger than 65535. The problem is that files temporarily saved by OpenOffice.org can no longer be removed by the program itself, but rather only by the system administrator (e.g. /tmp/OSL_PIPE_xxx ). The result is that OpenOffice.org cannot be started. The problem is in the ReiserFS file system and has been fixed in version 3.6 and higher. »
Now you can understand why. And yes, it’s weird.
In my case (Mandrake 9.0 and Slackware 9.1 uses a stable Reiser version = not the latest) it couldn’t even start the install properly.
_____________________
I like XFS and also JFS, the last (JFS) seems to make the start up faster and the disk noise is stranger when you listen to it (if you like to pay attention).
I also install with linux on software raid with 2 disks sometimes – RedHat and Mandrake work good on this was it last time with ~64k block size ? — to test differences, but if the FS isn’t on the kernel better not try it…
maybe 2.6 will have even more enhancements for soft raid XFS.
Extended attributes are usually used for ACLs.
Extents:
http://www.faqs.org/faqs/os-research/part1/section-12.html
From what I can tell, XFS is a hybrid (like more fs, I believe), where is logs for awhile, then updates the disk structure (which is stored in extents).
>What I would like to see is an announcement that HFS/HFS+ is
>being merged into the 2.6 kernel. Kinda need it for my iPod.
That would be great, but just FYI:
There is at least one HFS+ driver for Linux…
http://www.ardistech.com/hfsplus/
Also, the Windows-branded iPods run FAT32, and the others can be reformatted.
Very helpful info! Thanks a lot!