I can determine that the XFS file system is supported. But it does not appear to be mainstream (e.g. no mkfs.xfs etc). Abut two years ago it was used for large (>4TB) and fast file systems.
What is the current status of XFS. Most all of the documentation I have been able to locate date from the last century.
don
On Sat, 2005-12-24 at 10:57 -0700, don fisher wrote:
I can determine that the XFS file system is supported. But it does not appear to be mainstream (e.g. no mkfs.xfs etc). Abut two years ago it was used for large (>4TB) and fast file systems.
What is the current status of XFS. Most all of the documentation I have been able to locate date from the last century.
When you boot the Fedora installer, add "xfs" to the list of the parameters at the very first prompt. E.g. "linux text xfs" (or "linux xfs text", can't remember the correct order) for a text-based install that activates XFS.
You can then create XFS partitions with the installer. The XFS utilities will be installed automatically.
It is recommended to use XFS on partitions which contain very large files that are read/written at high speeds. E.g. video capture, MythTV, etc. XFS is the best performer in that case.
I am using it all the time on my 200GB multimedia/MythTV partition with FC4 and works extremely well.
Florin Andrei írta:
On Sat, 2005-12-24 at 10:57 -0700, don fisher wrote:
I can determine that the XFS file system is supported. But it does not appear to be mainstream (e.g. no mkfs.xfs etc). Abut two years ago it was used for large (>4TB) and fast file systems.
What is the current status of XFS. Most all of the documentation I have been able to locate date from the last century.
When you boot the Fedora installer, add "xfs" to the list of the parameters at the very first prompt. E.g. "linux text xfs" (or "linux xfs text", can't remember the correct order) for a text-based install that activates XFS.
You can then create XFS partitions with the installer. The XFS utilities will be installed automatically.
It is recommended to use XFS on partitions which contain very large files that are read/written at high speeds. E.g. video capture, MythTV, etc. XFS is the best performer in that case.
I am using it all the time on my 200GB multimedia/MythTV partition with FC4 and works extremely well.
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot. And most of the time the Oops points to the xfs driver. :-(
Fortunately JOE and other editors close the backup file after saving. But I had to reinstall several RPMs on such occasions because prelink or ldconfig was running at the time of the crash. I never had such a problem with EXT3 before. I run kernel.org kernels and 2.6.15-rc4-git2 still gives me problems.
Best regards, Zoltán Böszörményi
On Mon, 26 Dec 2005, Zoltan Boszormenyi wrote:
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot. And most of the time the Oops points to the xfs driver. :-(
Fortunately JOE and other editors close the backup file after saving. But I had to reinstall several RPMs on such occasions because prelink or ldconfig was running at the time of the crash. I never had such a problem with EXT3 before. I run kernel.org kernels and 2.6.15-rc4-git2 still gives me problems.
What disks/controllers are you using? What size stack?
George N. White III írta:
On Mon, 26 Dec 2005, Zoltan Boszormenyi wrote:
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot. And most of the time the Oops points to the xfs driver. :-(
Fortunately JOE and other editors close the backup file after saving. But I had to reinstall several RPMs on such occasions because prelink or ldconfig was running at the time of the crash. I never had such a problem with EXT3 before. I run kernel.org kernels and 2.6.15-rc4-git2 still gives me problems.
What disks/controllers are you using? What size stack?
Drive is a Maxtor 120GB in UDMA6 (ATA133?) mode. Controller is the built-in VIA ATA interface in the K8T800 chipset. System is FC43/x86-64, I don't remember having any stack size choices in make menuconfig.
Best regards, Zoltán Böszörményi
On Mon, 2005-12-26 at 18:46 +0100, Zoltan Boszormenyi wrote:
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot.
It's best if there's a match between the tools and the purpose.
XFS was designed first and foremost for performance. Clean behaviour in the case of sudden loss of power to the processing unit is not exactly a high-priority design constraint for systems such as these...
...since the processing unit is always behind at least one layer of backup/redundant/uninterruptible power supplies.
However, the highest performance possible is one of (if not THE) most important design constraints. Another assumption behind XFS is that storage is the best quality and therefore it does not lie when it reports back that the data was flushed all the way to the magnetic layer (which is something that cheap IDE drives/cards lie about, sometimes).
Bottom line: use Ext3 for the general-purpose partitions. Use XFS for your MythTV partition, or the one used to do video capture, DVD backups, ISO images, etc. At least that's what I do.
And most of the time the Oops points to the xfs driver.
It's been many years since I've last seen an oops on healthy hardware while using a "vanilla" Fedora / Red Hat install, with or without XFS.
Florin Andrei írta:
On Mon, 2005-12-26 at 18:46 +0100, Zoltan Boszormenyi wrote:
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot.
It's best if there's a match between the tools and the purpose.
XFS was designed first and foremost for performance. Clean behaviour in the case of sudden loss of power to the processing unit is not exactly a high-priority design constraint for systems such as these...
...since the processing unit is always behind at least one layer of backup/redundant/uninterruptible power supplies.
However, the highest performance possible is one of (if not THE) most important design constraints. Another assumption behind XFS is that storage is the best quality and therefore it does not lie when it reports back that the data was flushed all the way to the magnetic layer (which is something that cheap IDE drives/cards lie about, sometimes).
Bottom line: use Ext3 for the general-purpose partitions. Use XFS for your MythTV partition, or the one used to do video capture, DVD backups, ISO images, etc. At least that's what I do.
I wanted XFS for that purpose, too.
Anyway, I intend to retire this 2 years old Maxtor, please suggest a SATA drive that would be reliable. Is IBM/Hitachi Deskstar known to not lie about the flush?
And most of the time the Oops points to the xfs driver.
It's been many years since I've last seen an oops on healthy hardware while using a "vanilla" Fedora / Red Hat install, with or without XFS.
I have reported a "Bad page state" for vanilla 2.6.14 on LKML, XFS was definitely involved:
Bad page state at prep_new_page (in process 'cc1', page ffff8100011e1278) flags:0x4000000000000004 mapping:0000000000000000 mapcount:0 count:-2228224 Backtrace:
Call Trace:<ffffffff8015def1>{bad_page+113} <ffffffff8015ea01>{buffered_rmqueue+609} <ffffffff8015ec93>{__alloc_pages+243} <ffffffff8016add7>{do_no_page+279} <ffffffff8016b339>{__handle_mm_fault+425} <ffffffff8017c913>{do_sync_read+211} <ffffffff80352646>{do_page_fault+998} <ffffffff8822505e>{:xfs:xfs_inactive_free_eofblocks+174} <ffffffff88225240>{:xfs:xfs_release+160} <ffffffff80195f13>{dput+35} <ffffffff8017dce7>{__fput+375} <ffffffff8010f369>{error_exit+0}
Trying to fix it up, but a reboot is needed
Best regards, Zoltán Böszörményi
On Sunday 01 January 2006 06:47, Zoltan Boszormenyi wrote:
Florin Andrei írta:
On Mon, 2005-12-26 at 18:46 +0100, Zoltan Boszormenyi wrote:
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot.
It's best if there's a match between the tools and the purpose.
XFS was designed first and foremost for performance. Clean behaviour in the case of sudden loss of power to the processing unit is not exactly a high-priority design constraint for systems such as these...
...since the processing unit is always behind at least one layer of backup/redundant/uninterruptible power supplies.
However, the highest performance possible is one of (if not THE) most important design constraints. Another assumption behind XFS is that storage is the best quality and therefore it does not lie when it reports back that the data was flushed all the way to the magnetic layer (which is something that cheap IDE drives/cards lie about, sometimes).
Bottom line: use Ext3 for the general-purpose partitions. Use XFS for your MythTV partition, or the one used to do video capture, DVD backups, ISO images, etc. At least that's what I do.
I wanted XFS for that purpose, too.
Anyway, I intend to retire this 2 years old Maxtor, please suggest a SATA drive that would be reliable. Is IBM/Hitachi Deskstar known to not lie about the flush?
Is that not a typo above, and should be IBM/Hitachi DeathStar?
And most of the time the Oops points to the xfs driver.
It's been many years since I've last seen an oops on healthy hardware while using a "vanilla" Fedora / Red Hat install, with or without XFS.
I have reported a "Bad page state" for vanilla 2.6.14 on LKML, XFS was definitely involved:
Bad page state at prep_new_page (in process 'cc1', page ffff8100011e1278) flags:0x4000000000000004 mapping:0000000000000000 mapcount:0 count:-2228224 Backtrace:
Call Trace:<ffffffff8015def1>{bad_page+113} <ffffffff8015ea01>{buffered_rmqueue+609} <ffffffff8015ec93>{__alloc_pages+243} <ffffffff8016add7>{do_no_page+279} <ffffffff8016b339>{__handle_mm_fault+425} <ffffffff8017c913>{do_sync_read+211} <ffffffff80352646>{do_page_fault+998} <ffffffff8822505e>{:xfs:xfs_inactive_free_eofblocks+174} <ffffffff88225240>{:xfs:xfs_release+160} <ffffffff80195f13>{dput+35} <ffffffff8017dce7>{__fput+375} <ffffffff8010f369>{error_exit+0}
Trying to fix it up, but a reboot is needed
Best regards, Zoltán Böszörményi
Gene Heskett írta:
On Sunday 01 January 2006 06:47, Zoltan Boszormenyi wrote:
Florin Andrei írta:
On Mon, 2005-12-26 at 18:46 +0100, Zoltan Boszormenyi wrote:
Well, I have installed FC3 that way (XFS on most partitions) and now I regret it. All the time I have a power failure (very rare) or a kernel crash, all the files that were opened O_RDWR contain only zeroes after reboot.
It's best if there's a match between the tools and the purpose.
XFS was designed first and foremost for performance. Clean behaviour in the case of sudden loss of power to the processing unit is not exactly a high-priority design constraint for systems such as these...
...since the processing unit is always behind at least one layer of backup/redundant/uninterruptible power supplies.
However, the highest performance possible is one of (if not THE) most important design constraints. Another assumption behind XFS is that storage is the best quality and therefore it does not lie when it reports back that the data was flushed all the way to the magnetic layer (which is something that cheap IDE drives/cards lie about, sometimes).
Bottom line: use Ext3 for the general-purpose partitions. Use XFS for your MythTV partition, or the one used to do video capture, DVD backups, ISO images, etc. At least that's what I do.
I wanted XFS for that purpose, too.
Anyway, I intend to retire this 2 years old Maxtor, please suggest a SATA drive that would be reliable. Is IBM/Hitachi Deskstar known to not lie about the flush?
Is that not a typo above, and should be IBM/Hitachi DeathStar?
If I understand it right, the DeskStar drives are likely to die soon despite the 3 years warranty. :-( Then please suggest another SATA NCQ capable drive that YOU would buy for your own machine and has a 150+ MB capacity. :-)
Best regards,
Zoltán Böszörményi
On Sun, 2006-01-01 at 12:47 +0100, Zoltan Boszormenyi wrote:
Florin Andrei írta:
Another assumption behind XFS is that storage is the best quality and therefore it does not lie when it reports back that the data was flushed all the way to the magnetic layer (which is something that cheap IDE drives/cards lie about, sometimes).
Is IBM/Hitachi Deskstar known to not lie about the flush?
I am almost certain that I've seen a free software tool on the Internet a while ago that did exactly this: it could tell whether the hard-drive and/or the controller lie about flushing the data all the way to the magnetic platter. I think the technique involved yanking the power cord or hitting the reset button (different failures, perhaps it's worth testing both) while the software was doing some complex read/write operations with the disk. After reboot, the same application looked at the disk and could tell whether the data was properly flushed or not.
I can't remember the name of the software or anything, but I imagine that a clever google search would reveal it.
On Sat, 24 Dec 2005, don fisher wrote:
I can determine that the XFS file system is supported. But it does not appear to be mainstream (e.g. no mkfs.xfs etc). Abut two years ago it was used for large (>4TB) and fast file systems.
And is still used for things like numerical simulations, rendering, and remote sensing invlving terrabyte's of data where downtime is expensive and thruput is important. XFS tries to ensure that the filesystem is always consistent, so rebooting a huge after a crash does not require running fsck for days before the system can be used.
What is the current status of XFS. Most all of the documentation I have been able to locate date from the last century.
Maybe you were looking at docs on RH systems. There is an active mailing list. SGI (who still support XFS as an open source project) has begun using SUSE on their Itanium machines, so XFS is certainly being used by the people who really need it.
There can be problems with XFS, especially if you get into edgy workloads/hardware configurations, on 32-bit Intel (depending on the devices) with the 4-k stacks on RH. Most people who really need XFS will be using 64-bit processors. Some people have been running XFS on 32-bit hardware in FC[34] without problems, but I suspect they have been lucky with the workloads and hardware.
El lun, 26-12-2005 a las 12:03 -0400, George N. White III escribió:
On Sat, 24 Dec 2005, don fisher wrote:
I can determine that the XFS file system is supported. But it does not appear to be mainstream (e.g. no mkfs.xfs etc). Abut two years ago it was used for large (>4TB) and fast file systems.
And is still used for things like numerical simulations, rendering, and remote sensing invlving terrabyte's of data where downtime is expensive and thruput is important. XFS tries to ensure that the filesystem is always consistent, so rebooting a huge after a crash does not require running fsck for days before the system can be used.
What is the current status of XFS. Most all of the documentation I have been able to locate date from the last century.
Maybe you were looking at docs on RH systems. There is an active mailing list. SGI (who still support XFS as an open source project) has begun using SUSE on their Itanium machines, so XFS is certainly being used by the people who really need it.
There can be problems with XFS, especially if you get into edgy workloads/hardware configurations, on 32-bit Intel (depending on the devices) with the 4-k stacks on RH. Most people who really need XFS will be using 64-bit processors. Some people have been running XFS on 32-bit hardware in FC[34] without problems, but I suspect they have been lucky with the workloads and hardware.
-- George N. White III aa056@chebucto.ns.ca
I'm been following this thread with some interest, now just to contribute a single fact more: end-user i80x86 32-bit system, 7 months fc4 running, 7 months running xfs partitions, but only in the /mnt branch, as huge, extended partitions; p2p and multimedia use, so file sizes are, in general, of hundreds of MB minimum; No one problem there. Great. Efficiency, in two words...
Regards
On Mon, 26 Dec 2005, M Daniel R M wrote:
I'm been following this thread with some interest, now just to contribute a single fact more: end-user i80x86 32-bit system, 7 months fc4 running, 7 months running xfs partitions, but only in the /mnt branch, as huge, extended partitions; p2p and multimedia use, so file sizes are, in general, of hundreds of MB minimum; No one problem there. Great. Efficiency, in two words...
What disks/controller are you using? Have you ever useded any of the xfs_.. tools?
What disks/controller are you using? Have you ever useded any of the xfs_.. tools?
-- George N. White III aa056@chebucto.ns.ca
There are 2 basic Serial ATA (up to 150MB/s) HD's -120GB and 160GB respectively. Actually the system lives in the first one, whereas there are 2 huge xfs partitions filling up the second one.
Silicon Image Si 3112 controller (integrated).
If my corresponding mini-note (taken at that time) is right, I'm in condition to remember ;-) that I used the mkfs.xfs command to give that FS format to both partitions. BTW, partitions -according with that mini-note I wrote- had to be created yet, so first I had to use parted for that. Apart from that.., nope, there haven't been any further contact with xfs tools since then.
Regards
-
don fisher -
Florin Andrei -
Gene Heskett -
George N. White III -
M Daniel R Magarzo -
Zoltan Boszormenyi