It's not really a file system issue as much as a VM issue. RAID1/5 does nasty tricks to the buffer cache during resync that breaks the write ordering requirements for journaling file systems.
Actually, the RAID code has been fixed in 2.2.<late> and 2.4.0pre<mumble>, but I haven't had a chance to look at it yet. I suspect supporting XFS will still take some work. We'll get there.
When people mention incompatibilities between journaling and software RAID, they refer to RAID1 and RAID5. RAID0 is trivial block remapping and doesn't suffer from these problems.
XFS works with RAID0. RAID1/5 is a bit more tricky, but we'll get to it.
Re:JFS is nice, but I'm concerned...
on
XFS Beta
·
· Score: 4
First of all, XVM (the successor to XLV) is being ported to Linux. It's a prerequisite for CXFS - the clustered version of XFS - and furthermore we want
customers to be able to move disk arrays between Linux and IRIX systems.
You can use XFS on Linux with LVM and MD RAID0.
RAID1 and RAID5 might cause problems, because both they and XFS do nasty VM tricks. Since we're determined to go the kiobuf route in terms of I/O, that's were our efforts are concentrated. I'm working on adding kiobuf support to LVM as I type this. MD is next on my list.
Finally, the man pages have been updated for Linux. They're just not on the web page yet. We weren't supposed to release the beta until Friday, but we accidentally published the beta release web page and it was on Linuxtoday/Slashdot in no time.
We're updating the docs as fast as we can. Hang in there.
Re:compiler problems but yeah SGI DRT
on
XFS Beta
·
· Score: 5
This is a beta, and we've only done rudimentary performance tuning. Depending on your setup and workload, XFS yields results on par or slightly better than ext2.
We're working on replacing the current block I/O subsystem in Linux (aimed at 2.5, but will exist in the XFS tree in 2.4). Currently, Linux does block I/O in entities known as buffer_heads, which carry 512 byte payloads. The new scheme is based upon Stephen Tweedie's kiobuf model, and will support big (SCSI supports up to 16 MB/req) I/Os. XFS was primarily designed for big sustained I/Os and once we're done with the kiobuf support we'll start profiling the code and push it to the limits.
Regarding ports to other architectures: My Alpha here at the office is running XFS, but I haven't committed the changes yet. I ported XFS to it for fun a month ago but never got around to committing the changes. I'll do that at some point. And possibly look at SPARC.
But then again. This is Open Source. Feel free to hack on it and send us patches!
We require egcs 1.1.2 because it's Known To Work(tm).
We had a lot of issues when using gcc 2.95.2, and we didn't want to fight broken compilers during the beta testing period. Consequently, we've
set a fairly restrictive set of prerequisites.
Slashdot Mirror
Actually, the RAID code has been fixed in 2.2.<late> and 2.4.0pre<mumble>, but I haven't had a chance to look at it yet. I suspect supporting XFS will still take some work. We'll get there.
XFS works with RAID0. RAID1/5 is a bit more tricky, but we'll get to it.
You can use XFS on Linux with LVM and MD RAID0. RAID1 and RAID5 might cause problems, because both they and XFS do nasty VM tricks. Since we're determined to go the kiobuf route in terms of I/O, that's were our efforts are concentrated. I'm working on adding kiobuf support to LVM as I type this. MD is next on my list.
Finally, the man pages have been updated for Linux. They're just not on the web page yet. We weren't supposed to release the beta until Friday, but we accidentally published the beta release web page and it was on Linuxtoday/Slashdot in no time. We're updating the docs as fast as we can. Hang in there.
We're working on replacing the current block I/O subsystem in Linux (aimed at 2.5, but will exist in the XFS tree in 2.4). Currently, Linux does block I/O in entities known as buffer_heads, which carry 512 byte payloads. The new scheme is based upon Stephen Tweedie's kiobuf model, and will support big (SCSI supports up to 16 MB/req) I/Os. XFS was primarily designed for big sustained I/Os and once we're done with the kiobuf support we'll start profiling the code and push it to the limits.
Regarding ports to other architectures: My Alpha here at the office is running XFS, but I haven't committed the changes yet. I ported XFS to it for fun a month ago but never got around to committing the changes. I'll do that at some point. And possibly look at SPARC.
But then again. This is Open Source. Feel free to hack on it and send us patches!
We had a lot of issues when using gcc 2.95.2, and we didn't want to fight broken compilers during the beta testing period. Consequently, we've
set a fairly restrictive set of prerequisites.