I tried doing an install of Suse 10.1 using the XFS filesystem instead of reiserFS on my main desktop computer. The install seemed to go much quicker. I am trying this to see if this would be a faster or better performing alternative to reiserFS which I am using on my laptop computer. I was wondering what other people's experiences have been like with this file system. Thanks Ralph Ellis
On 5/15/06, Ralph Ellis
I tried doing an install of Suse 10.1 using the XFS filesystem instead of reiserFS on my main desktop computer. The install seemed to go much quicker. I am trying this to see if this would be a faster or better performing alternative to reiserFS which I am using on my laptop computer. I was wondering what other people's experiences have been like with this file system. Thanks Ralph Ellis
XFS on a laptop, you really have to joking. XFS does NOT do well with unexpected shutdowns. In particular it can fill files that are open at shutdown with nulls. I personally would not use XFS unless I had dual power-supplies connected to dual UPSs. And yes, I do use XFS much of the time, but I have the above redundant power and I only use it for real data filesystems, not /, /usr, /var, etc. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
On Monday 15 May 2006 07:31 pm, Greg Freemyer wrote:
XFS does NOT do well with unexpected shutdowns. In particular it can fill files that are open at shutdown with nulls. I personally would not use XFS unless I had dual power-supplies connected to dual UPSs. And yes, I do use XFS much of the time, but I have the above redundant power and I only use it for real data filesystems, not /, /usr, /var, etc.
If XFS needs dual power supplies and dual UPSs, what huge advantage does it have that makes it worth putting up with this? Bryan *************************************** Powered by Mepis Linux 3.4-3 KDE 3.5.2 KMail 1.8.3 This is a Microsoft-free computer Bryan S. Tyson bryantyson@earthlink.net ***************************************
On 5/15/06, Bryan S. Tyson
On Monday 15 May 2006 07:31 pm, Greg Freemyer wrote:
XFS does NOT do well with unexpected shutdowns. In particular it can fill files that are open at shutdown with nulls. I personally would not use XFS unless I had dual power-supplies connected to dual UPSs. And yes, I do use XFS much of the time, but I have the above redundant power and I only use it for real data filesystems, not /, /usr, /var, etc.
If XFS needs dual power supplies and dual UPSs, what huge advantage does it have that makes it worth putting up with this?
Bryan
I believe it was designed for high-speed video feeds. So if you have an application that needs lots of high-speed streaming data, XFS is a great solution. Also, most data centers setups have dual PS/dual UPS, so it is not big problem for Enterprise Server users. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
On Mon, 2006-05-15 at 19:55 -0400, Bryan S. Tyson wrote:
If XFS needs dual power supplies and dual UPSs, what huge advantage does it have that makes it worth putting up with this?
In addition to many feature and scalability benefits, it is a traditional UNIX filesystem design and doesn't require a lot of the "hacks" that non-UNIX filesystem designs like ReiserFS requires. E.g., there's a reason why Red Hat doesn't support ReiserFS -- a good segment of their enterprise clientel needs reliable NFS services. NFS shares on ReiserFS continues to be a major PITA, support-wise. Now I just wish Red Hat would support XFS, because Ext3 has a lot of scalability issues (before we start looking at features). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
Bryan J. Smith wrote:
On Mon, 2006-05-15 at 19:55 -0400, Bryan S. Tyson wrote:
If XFS needs dual power supplies and dual UPSs, what huge advantage does it have that makes it worth putting up with this?
In addition to many feature and scalability benefits, it is a traditional UNIX filesystem design and doesn't require a lot of the "hacks" that non-UNIX filesystem designs like ReiserFS requires.
E.g., there's a reason why Red Hat doesn't support ReiserFS -- a good segment of their enterprise clientel needs reliable NFS services. NFS shares on ReiserFS continues to be a major PITA, support-wise.
Now I just wish Red Hat would support XFS, because Ext3 has a lot of scalability issues (before we start looking at features).
I have found on my desktop system that copying DVD video files is relatively fast with the new filesystem. Also large program files seem to load faster than they did under my old set up with Suse 10 and reiserFS. It will be a few weeks before I have a really good sense of how significant these differences are. I have found that coping large DVD files under Suse and K3b is faster than comparable Windows programs possibly due to less system overhead and a more efficient cache set up with K3b. Thanks Ralph Ellis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-05-15 at 19:55 -0400, Bryan S. Tyson wrote:
If XFS needs dual power supplies and dual UPSs, what huge advantage does it have that makes it worth putting up with this?
For instance, it has dedicated administration tools, like xfs_freeze, xfs_growfs, xfs_copy... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEaaWQtTMYHG2NR9URAnDVAJ0TzbcTiMGz08N/34AkSM1wVKRl9wCfXK+9 2uF9zwT6GPiOGaZ+eK/+Rn0= =vefL -----END PGP SIGNATURE-----
On Tue, 2006-05-16 at 12:12 +0200, Carlos E. R. wrote:
For instance, it has dedicated administration tools, like xfs_freeze, xfs_growfs, xfs_copy...
Add xfsdump to that list. The on-line and off-line utilities are just _damn_mature_ after 10 years, because the filesystem organization has _not_ changed (_unlike_ ReiserFS**). XFS was the very first journaling filesystem with Quota, POSIX ACL / Extended Attribute and other support under Linux. e2dump only recently got XATTR capability, and star with its XATTR store has been "shaky" of a solution for me in the past. So as much as I also like Ext3 for not changing as well, it clearly lags XFS in features and utilities with a long, production history. -- Bryan **NOTE: I applaud SuSE for having the best damn ReiserFS implementation of any distro. And I _do_ think ReiserFS has a good journal and on-line recovery mechanism in the kernel. But the problem with ReiserFS for me has always been when it needs an off-line fsck. And that's when the off-line utility doesn't always match the kernel implementation ... and bam! No more data. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-05-16 at 07:17 -0400, Bryan J. Smith wrote:
On Tue, 2006-05-16 at 12:12 +0200, Carlos E. R. wrote:
For instance, it has dedicated administration tools, like xfs_freeze, xfs_growfs, xfs_copy...
Add xfsdump to that list.
True, I was looking for it, but the name escaped my sight; it has a different pattern - I wonder why? And reiserfs does not have a dump utility, I understand. Some people recommend ext3 for the system and xfs for home. I like reiserfs, but I have been bitten before... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEab5LtTMYHG2NR9URAtLZAJ4/3PaY6LIk4XD0nU1uU8sll/aXjACfXiZk YLAn/Vk2sWL+qIvEwFvlujs= =Ixpj -----END PGP SIGNATURE-----
On Tue, 2006-05-16 at 13:58 +0200, Carlos E. R. wrote:
Some people recommend ext3 for the system and xfs for home. I like reiserfs, but I have been bitten before...
Again, my professional opinion continues to be that SuSE has the best ReiserFS implementation out there -- especially when it comes to syncing up the off-line tools with the kernel. I don't want to speak too negatively in that regard, as some people have been running ReiserFS without issue. But in other regards, ReiserFS non-traditional design continues to show various compatibility issues with various, standard Linux kernel interfaces and support. Hence why it's a non-option for many people, including myself. I've been shy to deploy XFS the last few years. In the "good 'ole days" of SGI releasing official XFS packages and 2.4 kernels for Red Hat Linux 7.3 and 9, I could trust it explicitly. Unfortunately, the stock kernel implementation of XFS in 2.6 hasn't been nearly as solid -- unless you yank out select releases from SGI's own CVS repository. And forget the 2.4 backport, it was a "bad idea" IMHO. Now there are people on the SGI XFS list that like SuSE's stock XFS implementation. And there are others that balk at it. With the limitations of Ext3 that are an increasing issue, I sure wish Red Hat would put its efforts into supporting XFS as its enterprise filesystem. Until then, I'm solely Ext3 on RHEL and SLES. And that means I'm actually recommending and deploying Solaris/Opteron, instead of RHEL or SLES/Opteron, when it comes to enterprise file server duties. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
Greg Freemyer skrev:
On 5/15/06, Ralph Ellis
wrote: I tried doing an install of Suse 10.1 using the XFS filesystem instead of reiserFS on my main desktop computer. The install seemed to go much quicker. I am trying this to see if this would be a faster or better performing alternative to reiserFS which I am using on my laptop computer. I was wondering what other people's experiences have been like with this file system. Thanks Ralph Ellis
XFS on a laptop, you really have to joking.
XFS does NOT do well with unexpected shutdowns. In particular it can fill files that are open at shutdown with nulls. I personally would not use XFS unless I had dual power-supplies connected to dual UPSs.
And yes, I do use XFS much of the time, but I have the above redundant power and I only use it for real data filesystems, not /, /usr, /var, etc.
Greg
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems... Anders.
On 5/16/06, Anders Norrbring
Greg Freemyer skrev:
On 5/15/06, Ralph Ellis
wrote: I tried doing an install of Suse 10.1 using the XFS filesystem instead of reiserFS on my main desktop computer. The install seemed to go much quicker. I am trying this to see if this would be a faster or better performing alternative to reiserFS which I am using on my laptop computer. I was wondering what other people's experiences have been like with this file system. Thanks Ralph Ellis
XFS on a laptop, you really have to joking.
XFS does NOT do well with unexpected shutdowns. In particular it can fill files that are open at shutdown with nulls. I personally would not use XFS unless I had dual power-supplies connected to dual UPSs.
And yes, I do use XFS much of the time, but I have the above redundant power and I only use it for real data filesystems, not /, /usr, /var, etc.
Greg
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems...
Anders.
Sorry Anders, I started using XFS back in SuSE 8.0 (or 8.1) days when SuSE first started supporting it. Since then I've tracked it (and it's bugs) closely, but I've never used JFS. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
Anders Norrbring wrote:
What are your NSHO ( ;-) ) about JFS?
Greg Freemyer wrote:
Since then I've tracked it (and it's bugs) closely, but I've never used JFS.
IBM's JFS has the same problems as ReiserFS, it was _not_ a traditional UNIX design. It is a common _misconception_ that JFS was ported from AIX. JFS was actually ported from OS/2. The reasons for this are more legal than anything. Long story short, IBM was prevented in a Non-Compete Clause in the Project Monterey Contract (with SCO) from porting any work from Monterey/AIX to Linux/IA-64 or any 64-bit enhancements to Linux, such as AIX's 64-bit filesystem. This was in 1999, _before_ IBM decided to pull out of Project Monterey in 2000, and basically undercut Caldera 20 days after purchasing SCO (and the rest of that is for common debate). So, instead, IBM ported JFS from its original OS/2 foundation. This mean it lacked many of the inode features and compatibility that the AIX version had -- for quota, NFS, XATTR, etc... support. As such, JFS also has similar compatibility issues on Linux as did ReiserFS. In fact, IIRC, it's largely SGI's donations to the Linux VFS (virtual filesystem) layer in early 2.5.x developments that JFS and ReiserFS now have _some_ quota, NFS, XATTR, etc... compatibility (long story). XFS was ported from Irix _directly_ to Linux with *0* removed. In 2000, XFS was already a filesystem with a 7+ year, proven and _unchanged_ structural design. That's why it is very much trusted and proven in Linux -- with caveats (e.g., the 2.4 kernel lacked a lot of capability required for XFS features -- hence the SGI donations to 2.5.3+). ReiserFS was not a traditional UNIX filesystem design -- let alone its structure changes too much. While the kernel implementation and on-line check might accommodate this, I've just had too many issues with the off-line tools being "out-of-sync" with the on-line organization. And JFS, from OS/2, was not a traditional UNIX filesystem design either. I haven't kept up with it post-Monterey fall-out to see if IBM has changed its stance. As much as people argue back and forth about SCO's claims on IP in Linux (which I won't do here), the Non-Compete Clause of Project Monterey combined with IBM withholding all Monterey/IA-64 source code, is still the "main meat" of SCO's lawsuit (and not the "IP smokescreen" that was added in May when IBM didn't settle, after the original March filing). So it would not surprise me if IBM hasn't ported some of the AIX code, such as from JFS, to Linux because some of the rulings on Monterey-driven discoveries by judges thus far (again, _ignore_ the Linux IP stuff). And then there's also the fact that IBM still considers Linux to be the "younger sister product" to AIX, where they still have a lot of sales and profit -- one of the reasons they undercut Caldera once they purchased SCO (who was going to introduce the same split UNIX-Linux strategy -- and the Non-Compete Clause in Monterey being the whole reason Caldera thought they were "safe"). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
Anders, On Monday 15 May 2006 23:33, Anders Norrbring wrote:
...
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems...
Why *DON'T* you want XFS on that machine?
Anders.
RRS
Randall R Schulz skrev:
Anders,
On Monday 15 May 2006 23:33, Anders Norrbring wrote:
...
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems...
Why *DON'T* you want XFS on that machine?
Simply because it has a single line PSU and no UPS.. Anders.
On Tue, 2006-05-16 at 06:29 -0700, Randall R Schulz wrote:
Anders,
On Monday 15 May 2006 23:33, Anders Norrbring wrote:
...
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems...
Why *DON'T* you want XFS on that machine?
Perhaps they had a problem a couple of years ago. Once bitten, twice shy. I have been xfs for a few years both on a desktop and a laptop and have -not- had any problems. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Hi, On Tuesday 16 May 2006 07:40, Ken Schneider wrote:
On Tue, 2006-05-16 at 06:29 -0700, Randall R Schulz wrote:
Anders,
On Monday 15 May 2006 23:33, Anders Norrbring wrote:
...
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems...
Why *DON'T* you want XFS on that machine?
Perhaps they had a problem a couple of years ago. Once bitten, twice shy. I have been xfs for a few years both on a desktop and a laptop and have -not- had any problems.
I chose it with 9.0 and stuck with it since, on 9.1, 9.3 and 10.0. Power failures are a few-times-per-year event around here (plus the occasional screw-up by me) and I've never had any file system corruption or data loss issues when it's occurred. Am I just lucky, or is the risk overstated? Anyway, I'm moving soon and when I find a new place, I'm going to make sure there's enough office / machine space and I'll be putting in a UPS. Randall Schulz
On 5/16/06, Ken Schneider
On Tue, 2006-05-16 at 06:29 -0700, Randall R Schulz wrote:
Anders,
On Monday 15 May 2006 23:33, Anders Norrbring wrote:
...
Greg, What are your NSHO ( ;-) ) about JFS? I'm also looking at implementing a high performing FS on a client machine that shovels loads of files, both small and big, and I do *NOT* want XFS on that machine. Personally I prefer XFS myself, but then I do have redundancy all the way on my systems...
Why *DON'T* you want XFS on that machine?
Perhaps they had a problem a couple of years ago. Once bitten, twice shy. I have been xfs for a few years both on a desktop and a laptop and have -not- had any problems.
Ken, I'm curious, do you use X? I've personally don't keep home on XFS, but I've read numerous times about some of the config files being zero'd out upon unexpected shutdowns. Apparently it was very obvious to the users and they had to reset up their X (or KDE/Gnome/etc.) config. I really don't remember the details, but it certainly scared me away from using XFS for routine use. Also, the response from the XFS team on the mailing list was aways, we've done what we can to shorten the window, but by design XFS does not journal data, just meta-data. Therefore with an unexpected shutdown we can't always trust the data of certain open files and for those files we reset the content to nulls. Seriously it was a big and common complaint on the XFS mailing list for years. I personally have not been paying attention to XFS in the 2.6 kernel. I'm waiting for XFS/LVM snapshots to work more reliably before I consider upgrading any of my fileservers. FYI: I actually have upgraded a test fileserver and I get LVM snapshot failures simi-routinely on that server. In fact I had one over the weekend. That is one of things I want to test out 10.1 on to see if the snapshots are working better yet or not. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
On Tue, 2006-05-16 at 10:57 -0400, Greg Freemyer wrote:
On 5/16/06, Ken Schneider
wrote: On Tue, 2006-05-16 at 06:29 -0700, Randall R Schulz wrote: Perhaps they had a problem a couple of years ago. Once bitten, twice shy. I have been xfs for a few years both on a desktop and a laptop and have -not- had any problems.
Ken,
I'm curious, do you use X? I've personally don't keep home on XFS, but I've read numerous times about some of the config files being zero'd out upon unexpected shutdowns. Apparently it was very obvious to the users and they had to reset up their X (or KDE/Gnome/etc.) config.
Yes, I run KDE on both. These are both personal machines.
I really don't remember the details, but it certainly scared me away from using XFS for routine use.
Also, the response from the XFS team on the mailing list was aways, we've done what we can to shorten the window, but by design XFS does not journal data, just meta-data. Therefore with an unexpected shutdown we can't always trust the data of certain open files and for those files we reset the content to nulls.
I have never had this issue.
Seriously it was a big and common complaint on the XFS mailing list for years. I personally have not been paying attention to XFS in the 2.6 kernel. I'm waiting for XFS/LVM snapshots to work more reliably before I consider upgrading any of my fileservers.
FYI: I actually have upgraded a test fileserver and I get LVM snapshot failures simi-routinely on that server. In fact I had one over the weekend. That is one of things I want to test out 10.1 on to see if the snapshots are working better yet or not.
Before I retired I had a samba server running using xfs so get the acl's to work. This machine was server docs to a few hundred employees without any problems. Think about it, if it was such a hugh issue SUSE -would not- allow it in the distribution since SUSE is about quality (that's why I use SUSE). -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Before I retired I had a samba server running using xfs so get the acl's to work. This machine was server docs to a few hundred employees without any problems. Think about it, if it was such a hugh issue SUSE -would not- allow it in the distribution since SUSE is about quality (that's why I use SUSE).
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
I just searched the xfs mailing list to see if the issue had been addressed. I found a full thread discussing it from a year ago: http://oss.sgi.com/archives/linux-xfs/2005-02/msg00086.html If you read it, you will see that the XFS team basically say the performance of XFS would be greatly degraded if they eliminated the window of opportunity. They describe the window as possibly being minutes long between a Meta-Data update that increases the filesize and the actual data being flushed to disk. A common activity that does this is saving a file in vim. When vim does a save the file will either be truncated to zero length and rewritten or ithe original will be renamed and a new file created and written to. Either way you have a multi-minute opportunity to have the file null filled. There was also a off the cuff reference to it last month, so I'm convinced it is still there and not significantly changed from the 2.4 kernel code I still use. Greg
On Tue, 2006-05-16 at 12:37 -0400, Greg Freemyer wrote:
If you read it, you will see that the XFS team basically say the performance of XFS would be greatly degraded if they eliminated the window of opportunity. They describe the window as possibly being minutes long between a Meta-Data update that increases the filesize and the actual data being flushed to disk.
I think people forget that all meta-data journaling filesystems are a set of hacks. They do *NOT* improve the integrity of your filesystem. They are *NOT* "true atomic commits." The "main reason" for a meta-data journaling filesystem is to reduce or eliminate the filesystem integrity check. The filesystem integrity check merely puts the filesystem in a "consistent" state, and does *NOT* necessarily mean you didn't have data loss. If you are "anal" on integrity, but want to reduce recovery time to make a filesystem inconsistent, the "most reliable" approach is as follows ... 1. Filesystem with full data journaling 2. Non-volatile RAM (NVRAM) for full data journal 3. Firmware "supervisor" for NVRAM/disk buffer flush/recovery 4. An integrated volume management and filesystem #1-4 is essentially what NetApp's Data OnTap OS and WAFL integrated volume management and filesystem does. It not only does full data journaling, but uses a NVRAM board and a firmware "supervisor" to ensure all NVRAM/disk buffer is flushed/recovered in the case of a system crash, loss of power, etc... Now prior to its leaving the hardware business, VA Linux / Research _did_ sell Linux 2.2 solutions with early, full data journaling-only Ext3. They also included a NVRAM board for the data journal. This was #1-2. It came as close as you could get to a "most reliable" setup. It essentially _eliminated_ non-atomic commits as well as put the data to the NVRAM quickly. For those of us running the NFS v3 SGI/Trond/Higgen patches on late 2.2 kernels at the time, having this solution (Ext3 full data + NVRAM) meant we could run a _true_ NFS v3 sync operation that was just as fast as Linux's non-standards compliant NFS v2 async (which is not a valid IETF NFS v2 mode). It was a major blessing. Today, using a full data journal and NVRAM is largely overkill. But if you want the ultimate in "reliability/integrity," it's still not a bad idea. Unfortunately, Ext3 is now meta-data and the full data journaling code virtually hasn't been worked on since kernel 2.2 (i.e., I don't know if I trust it). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
On Tuesday 16 May 2006 10:08 am, Ken Schneider wrote:
I'm curious, do you use X? I've personally don't keep home on XFS, but I've read numerous times about some of the config files being zero'd out upon unexpected shutdowns. Apparently it was very obvious to the users and they had to reset up their X (or KDE/Gnome/etc.) config.
Yes, I run KDE on both. These are both personal machines.
I've switched to JFS or XFS exclusively since about 9.0. Too many problems with ReiserFS and inconsistencies/rebuilds with lockups, power outages, etc.
I really don't remember the details, but it certainly scared me away from using XFS for routine use.
Also, the response from the XFS team on the mailing list was aways, we've done what we can to shorten the window, but by design XFS does not journal data, just meta-data. Therefore with an unexpected shutdown we can't always trust the data of certain open files and for those files we reset the content to nulls.
I have never had this issue.
Me neither. JFS and XFS have been rock solid for me on servers, desktops and laptops.
Seriously it was a big and common complaint on the XFS mailing list for years. I personally have not been paying attention to XFS in the 2.6 kernel. I'm waiting for XFS/LVM snapshots to work more reliably before I consider upgrading any of my fileservers.
Before I retired I had a samba server running using xfs so get the acl's to work. This machine was server docs to a few hundred employees without any problems. Think about it, if it was such a hugh issue SUSE -would not- allow it in the distribution since SUSE is about quality (that's why I use SUSE).
SUSE's endorsement and continued support has me on XFS now since SUSE dropped boot/install support for JFS. From the issues that Greg mentions with "a file system" I had to double check that he meant XFS not Reiser.
Ken
Stan
On Tue, 2006-05-16 at 11:08 -0400, Ken Schneider wrote:
Before I retired I had a samba server running using xfs so get the acl's to work. This machine was server docs to a few hundred employees without any problems.
Allison's tenure at SGI did a lot for XFS -- not just on Irix, but also when XFS was ported to Linux.
Think about it, if it was such a hugh issue SUSE -would not- allow it in the distribution since SUSE is about quality (that's why I use SUSE).
Ummm, have to _differ_ there. _Compatibility_ is something that is clearly ignored by any distro that ships ReiserFS, let alone Linus' choice to include it in 2.4.1+. Now don't get me wrong, XFS is a solid filesystem in design and implementation. Other than the original XFS 1.0 release bug that took out one of my /var filesystems, I've experienced *0* data loss. But there are some serious compatibility issues with the stock kernel 2.6 version (let alone the 2.4 backport). Other than the official SGI releases -- and most of those were on old, heavily hacked/modified kernel 2.4 release. The newer 2.6 (and 2.4 backport) have caused me headaches. Enough that I went back to Solaris for mission-critical NFS+Samba file servers. Kinda said, because Red Hat Linux 9 + Official SGI XFS 1.3 was absolutely solid (as well as RHL7.3 + XFS 1.2 before it). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own
Anders Norrbring wrote:
Greg, What are your NSHO ( ;-) ) about JFS?
Just my 2 Rappen - we use JFS everywhere, and have done so for at least 3 years. Everywhere = all servers, workstations and laptops, probably 25 or more in total. The support/mailing-list is excellent, even in those exceedingly rare cases when something weird or unexpected happens. Power outages - we've probably had one per year over the last 5 years - JFS has never caused a problem. /Per Jessen, Zürich
participants (10)
-
Anders Norrbring
-
Bryan J. Smith
-
Bryan S. Tyson
-
Carlos E. R.
-
Greg Freemyer
-
Ken Schneider
-
Per Jessen
-
Ralph Ellis
-
Randall R Schulz
-
S Glasoe