Forwarded because I don't pay attention to reply-tos until it's too late.
---------- Forwarded message ----------
On Tue, Sep 23, 2008 at 1:26 PM, gary hildebrand [email protected] wrote:
I have a couple older distros of SuSE -- 6.4 & 7.2 and was wondering if there is an easy way to do it with a journaling FS? Whenever I'd get a hit/crash in ext2, it would sorta eat itself up, and then over a period of time, become unuseable. 6.4 has a wide variety of packages no longer available on the new distros, and I'd like to have a drive set up so I can boot it when wanted.
Journaling filesystems provide a few main features: fast fsck, data integrity and fast writes. Ext3 is the only FS I know of that allows full data journaling. The rest just journal metadata. Inodes, indirect blocks are write journaled, but the data itself isn't in reiser and XFS. I'm not even sure it's the default in ext3, but I know you can retune ext3 for full data. As for old SuSE kernels, I'm not sure whether they have ext3 in the kernel, or if you'll have to build it yourself.
I'm a bit curious, what does SuSE 6.4 have that's no longer available?
Justin Dugger
Journalling the files themselves would be redundant in XFS because new files and changes to files are Copy-on-write. The new sector is written first (even if the file isn't growing) then the metadata is updated. If any part of the write fails the metadata will be pointing back at the original sectors untainted by the failed write.
Don't go setting filesystem requirements like how Journaltastic it has to be, unless you know the limits of usefulness and relevance of those requirements. If you're going to set requirements don't base them on the inner workings of the filesystem, but what you need to do with it. (Survive power failures without filesystem corruption) When it comes time to choose a filesystem, pick ext3. It's just the right choice unless you think you need more than 8TB of filesystem space. XFS can do that, but you're better off using multiple ext3 filesystems, and symlinks.
Ext3 it (at least as of today) Linux' filesystem. Period. There are thousands of choices. Only one right one (ext), and ext's current extremely stable version is 3.
That said, if you need a sql driven filesystem, try fuse-mysqls: http://sourceforge.net/projects/mysqlfs/ http://www.linux.com/feature/127055?theme=print
Storing its data in mysql, you can use mysql's native high availability clustering to keep multiple instances on multiple machines in sync, at all times, without scripts, inotify, or a SAN. Just don't count on any degree of performance.
On Tue, Sep 23, 2008 at 6:06 PM, Billy Crook [email protected] wrote:
Journalling the files themselves would be redundant in XFS because new files and changes to files are Copy-on-write. The new sector is written first (even if the file isn't growing) then the metadata is updated. If any part of the write fails the metadata will be pointing back at the original sectors untainted by the failed write.
Is this a recent change? Because for a very long time, the XFS FAQ basically said "if it hurts, don't do it" when it comes to unclean shutdowns. I've never heard XFS described as copy on write.
Don't go setting filesystem requirements like how Journaltastic it has to be, unless you know the limits of usefulness and relevance of those requirements. If you're going to set requirements don't base them on the inner workings of the filesystem, but what you need to do with it. (Survive power failures without filesystem corruption) When it comes time to choose a filesystem, pick ext3. It's just the right choice unless you think you need more than 8TB of filesystem space. XFS can do that, but you're better off using multiple ext3 filesystems, and symlinks.
Ext3 it (at least as of today) Linux' filesystem. Period. There are thousands of choices. Only one right one (ext), and ext's current extremely stable version is 3.
I agree that ext3 is a great choice for stability and recovery. I've had plenty of unclean shutdowns without dataloss. There are, of course, psychopaths who want ext4 available in the next Ubuntu. But they're laughable, and the team tries to forward such requests to Theodore T'so's opinion on the subject.
Very shortly, there's going to be some new filesystems in order. btrfs and ext4 are both moving along and offer substantially different features. For example, btrfs does have copy on write semantics (http://lkml.org/lkml/2007/6/12/242).
Justin Dugger
I don't know about XFS-on-Linux, but I've used XFS on IRIX for ten years now and I've probably had a hundred unclean shutdowns. I've only once had data corruption, and that was recently when there was some kind of dirty power event that threw five disks and two controllers in my array.
Even then a simple xfs-repair fixed that problem. While my example is certainly anecdotal, folks may want to consider my assertion that XFS is certainly not fragile, at least not on IRIX.
Jeffrey.
On Tue, Sep 23, 2008 at 6:48 PM, Justin Dugger [email protected] wrote:
Is this a recent change? Because for a very long time, the XFS FAQ basically said "if it hurts, don't do it" when it comes to unclean shutdowns. I've never heard XFS described as copy on write.
On Tue, Sep 23, 2008 at 10:38 PM, Jeffrey Watts [email protected] wrote:
I don't know about XFS-on-Linux, but I've used XFS on IRIX for ten years now and I've probably had a hundred unclean shutdowns. I've only once had data corruption, and that was recently when there was some kind of dirty power event that threw five disks and two controllers in my array.
Similarly anecdotal, a dormmate of mine ran XFS for a while. Then one day he spilled some water near the extension cord and guitar amp he'd plugged into his UPS. In a frantic move he unplugged the wrong cable during an emerge and discovered a number of binaries full of ^@ (null).
When I asked friends about it, a veteran UNIX admin mentioned that IRIX was designed for SGI machines, high end all of them. Among their notable features is a power failure notification system capable of taking corrective action, because the power supply was designed to their specifications, rather than the PC market's. The same guy pointed me to SGI's own statement on the subject, archived by our good friends at archive.org:
http://web.archive.org/web/20030604071716/http://oss.sgi.com/projects/xfs/fa...
You'll note the question has been updated, but doesn't detail how it was fixed:
http://oss.sgi.com/projects/xfs/faq.html#nulls
Justin Dugger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Justin Dugger wrote:
Similarly anecdotal, a dormmate of mine ran XFS for a while. Then one day he spilled some water near the extension cord and guitar amp he'd plugged into his UPS. In a frantic move he unplugged the wrong cable during an emerge and discovered a number of binaries full of ^@ (null).
My XFS experience is similar...nasty problems with data corruption on unclean shutdowns with linux.
I now run JFS, which has worked almost flawlessly across many sudden unexpected power outages. I chose JFS over EXT3 several years ago mostly due to it's resizing features and some filesystem features.
Resizing a JFS partition is as simple as extending the logical volume it's on top of, and issuing a 'mount -o remount,resize <mountpoint>'. Takes all of a couple seconds. Resizing ext involves marching through the filesystem and mucking around with numerous bits of metadata, which takes forever and seems more prone to catastrophic failure.
I also occasionally tend to run out of inodes on ext file-systems, and I have found no easy way to increase them once the filesystem is online.
I'm hoping ext4 will address both issues, because while I love JFS, it's not getting a lot of current development, and the ext filesystems are far and away the most used/tested of the linux filesystems.
...oh the "almost" in almost flawlessly, above: I have several times run a JFS filesystem completely out of disk space. Once, this caused the filesystem to become corrupt and unmountable. A simple offline fsck fixed the problem, however, and all was well (once I acquired some additional storage, that is! :).
- -- Charles Steinkuehler [email protected]
-
Billy Crook -
Charles Steinkuehler -
Jeffrey Watts -
Justin Dugger