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 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

-----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-----

-----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-----

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.

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

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.

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 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

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

S Glasoe wrote:

SUSE's endorsement and continued support has me on XFS now since SUSE dropped boot/install support for JFS.

As an aside - JFS boot support is now back (10.1GM). /Per Jessen, Zürich

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