XFS merged in Linux 2.5

joib writes "According to this notice, the XFS journaling file system has been merged into Linus bitkeeper tree, to show up in 2.5.36." Ya just know someone out there wants to have every journaling file system on one drive just 'cuz.

Comments

Red Hat has XFS...

[NewbieSpaz]

For any of you Mandrake fans out there who like to bash Red Hat, and mention that Mandrake has had XFS file system included, while Red Hat does not, you would be wrong. While Red Hat does not officially support it, if at the installer's 'boot:' prompt you type in 'linux xfs', it works great. I've used it on a few systems with no problems.

But where is e2compr

[Kynde]

There are systems where we simply don't and won't have enough disk space and where speed is not of the essence. We have them now, and we will continue to have them in the future.

Being a linux developer for embedded production boxes and given the current increasing interest over linux in embedded along with embedded boxes typically running _WITHOUT_ hard disks (mostly just flash chips of some sort, due to their better life-time), I cannot help wondering why the kernel mailing list shows little or no interest towards ext2 (or ext3) compression.

JFFS and JFFS2 don't come into question in most cases as they tear through the fs layers and cannot be used with IDE flash chips for example.

Alcatel even released it two weeks ago for 2.4.17... loads of people, like me, must have ported it to 2.4.19 by now. But to get ext2 compression to 2.5.XX, forget it... but why?

This little like the lack interest towards under clocking, eventhough once you've overclocked your main computer to the max, you will start looking for more silent option, if not for the desktop computer, but for the closet firewall. Even if you don't have the interest now, you will, once you shack in with a gal.

Re:Silly question

[rseuhs]

XFS supports ACL's (or access control lists) which are much better than standard UNIX permissions.

Actually I think ACLs are the reason why everybody is running as Administrator in Windows. They are just too damn complicated.

The Unix-permissions are simple. You can understand the concept of user-group-all in a few minutes and there are only 2 commands to remember (chmod, chown).

Also, Unix-permissions have so far fit with everything I needed and in the rare case you really need something special, there is also sudo.

I think ACLs are only useful for a tiny minority, IMO. I certainly don't need it.

Boot partition

[mark_space2001]

> XFS enabled kernels are huge, and that creates a slight problem when booting from floppy.

I think the trick to this is to have a /boot partition, and a /root partition, and make them both ext2. Then you can boot from a floppy, and then boot the larger image on the boot partition. That was the reason given for having those partitions in the Linux Stadard Base documents, anyway.

But I'm an engineer, not an IT person, so I could be mistaken as I've never attempted to do it myself.

Re:Why is kernel-image so big?

[psamuels]

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've got two guesses. One, XFS has a lot of advanced features. For example, you can actually reserve disk bandwidth - assuming the disk goes a certain speed, XFS is prepared to guarantee your multimedia app that it can get a certain amount of data in or out per second. You can even have sub-partitions within your XFS partition, separated out so that only one sub-partition has guaranteed I/O rates. (I don't remember the details. It's all about multimedia, at any rate. (No pun intended.)) Then there are the more mundane features like ACLs and extended attributes.

Second, since XFS came from IRIX, I'm guessing the SGI engineers did what many people do when porting code from one system to another: reconstruct the original environment. I have no grounds for saying this - it's just a guess - but I can well imagine the SGI engineers deciding to port a lot of IRIX kernel functionality to the Linux kernel rather than adapt XFS to the native Linux way of doing things, which is a lot less featureful / bloated (pick your adjective).

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.

Nope, kjournald is part of the kernel - it's not a separate user-space daemon. You see it in your 'ps' output because it is a kernel thread. As such, it is scheduled like a userspace process, even though it isn't running a userspace program and never drops into user mode. Any time the Linux kernel spawns a new kernel thread, it will show up in 'ps' output that way. They usually try to name threads starting with 'k' so as to tip you off. Unfortunately this is probably not very effective for those of you who use certain non-GNOME desktop environments....