Mac OS X to Get Journaling FS
overunderunderdone writes "According to eWeek, Apple Computer is planning to introduce a new journaling file system code-named 'Elvis' with the 10.2.2 release. Supposedly it will run on top of HFS+ and will be turned off by default. Though it will cost you 10% to 15% performance penalty the article says it is more extensive than NTFS and is on par with BeOS's 64-bit journaling file system. Not surprising since it is being developed by the same person - Dominic Giampaolo." I've been super impressed by OS X having used it as my primary laptop for the last couple weeks. It really is a great unix box- and this is one of the important missing puzzle pieces.
I made the switch over last December. Love it. I was really more of a FreeBSD user, but you get the idea. It's wonderful to be able to have an attractive GUI with all too many bells and whistles to work with, but still be able to throw up a terminal window with bash and work with the real heart of things if you feel the need. Plus the ability to run XFree86 rootless on top of the GUI is nice.
-----
jonathan barket
i wish it would have been explained that way...
the writer of the eWeek article is Nick De Plumme (or something) - he's the guy from ThinkSecret....
hardly a "journalistic" website.
guns kill people like spoons make Rosie O'Donnell fat.
Pish. I have a Pismo (500MHz G3 PowerBook) and a 933 G4. While the G4 is a lot faster, the Pismo is a delight to use and leaves me with no complaints.
There should be a moratorium on the use of the apostrophe.
Max V.
NeXTMail/MIME Mail welcome
So you can have fun yanking out the power plug of your computer while its doing a write operation without the unpleasant experience on reboot. Most people (as in AOL Grandmas) don't need it but for servers, its a must. This will help beef up Mac OS X Server against Linux.
Strange women lying in ponds distributing swords is no basis for a system of government.
OS X doesn't really need a fast G4, any G4 is good as long as you have a shedload of RAM. That's the real OS X bottleneck, which is easily solved by a quick trip to Crucial.com.
Journaling your filesystem allows you to maintain integrity through a system crash or power outage. This doesn't mean you'll have all the data in your files uncorrupted (a point often missed by many), but rather that your filesystem won't become corrupted (you won't lose your filesystem because of a crash). Modern filesystems like the more recent Linux etxfs and XFS and Windows NTFS support journaling. It's an essential part of keeping your computer crash-resistant.
There is a cost, however. Journaling filesystems are slower than non-journaling because all file metadata update operations have to be written to a transaction log. This makes journaling a poor choice for some high-volume filesystems in scientific computing or other arenas where performance is uttermost (games). In most cases, however, the performance penalty is worth the added integrity.
Note that journaling your filesystem only keeps the metadata intact, not the file data itself. You can still loose data, such as the contents of a document you were editing but had not saved. For full transactional integrity you need the cost and overhead of a transactional database (SQLServer, Postgres, DB2, Oracle, etc.).
Journaling means that if your system isn't shut down cleanly, it won't take forever to fsck your disk the next time you start up. The journal will contain all the information the system needs to get the system into a consistent state after an unclean shutdown. In addition, if the system journals all data instead of just metadata (as most journaling systems seem to do) it will prevent data loss, too.
Also bear in mind that it won't cost you 10-15% of your system resources; it will slow down disk operations by 10-15%, which is a much smaller penalty. If you aren't doing really disk intensive stuff, you probably won't even notice the slowdown. If you are doing lots of disk intensive activities, you'll probably like the fact that you're less likely to be hosed if your system crashes in the middle of one.
There's no point in questioning authority if you aren't going to listen to the answers.
You get away with it because you aren't banging hard at the filesystem while yanking away at your cables. Try fulling loading your system with data copies back and forth to your iPod and an external hard drive, open your Mac box, and then on full disk load pull all cables (including internal hard drive connection). Try this a few times and you may have more luck. ;-)
This seems like an entirely new system, because the BSD type systems do not have journaling, and there is no such system on the forseable horizon.
FreeBSD provides something called softupdates, which do much to alievate the need for a journaling system. And it does this without the performance hit. When FreeBSD 5.0 comes out it will do something called snapshoting, which will bring even more stability (and background fsck) without much of a performance hit. NetBSD provides (I think) a different implementation of softupdates. OpenBSD might too, I don't know.
Which makes me very disappointed that apple chose this route. Softupdates+Snapshots solves the problem without the performance hit. BSD doesn't need no stinking journaling.
Jason Denton Colorado State University [Thoughs and comments are my own, and not reflective of CSU]
If you have ever had a Linux system running a non-journaling filesystem, you'd know. I had a box using ext2, a non-journaling fs, go down in a power failure. This baby had about 100 GB of space in ext2. It took at least an hour to get the system up because if a box crashes without journaling, it must check the drives for consistency.
In comparison, that same box using ext3, a journaling filesystem, takes a second or two to recover since it is not dependant on the size of the drives, but the (small) size of the journal (except if your drive hardware fails).
Also, journaling helps with data integrity in cases of failure as well, so you don't get files filled with garbage at the end.
If they are using anything close to BeOS's filesystem, use it. That was by far the best filesystem I have ever seen. Beautiful.
Fortran programmer...oh yeah. Array math for life!
"The diskspace used by the journal file in NTFS and this new filesystem can be put to much better use."
You mean like empty cluster tips?
NTFS might use a good amount of space, but you make up for allot of that just based on the smaller cluster sizes. Take a large directory (20,000+ files, 10GB+), put it on a Win2k machine with NTFS, then another with FAT32. Right click -> properties. Size on Disk says it all.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
Yep, you guessed it... B-tree was basically spaghetti: reformat and reinstall time. I've seen it happen a few times before: the most spectacular being a crash during a defrag. Basically, nothing pointed to the right file: all the icons were there, but the info in them was basically noise.
"Seven Deadly Sins? I thought it was a to-do list!"
"Note that journaling your filesystem only keeps the metadata intact, not the file data itself".
That depends on which journaling filesystem you use, and, sometimes, which mode you use it in.
For example, the Linux ext3 file system supports three different journaling modes: "journal", "ordered" and "writeback".
From the "mount" man page:
journal All data is committed into the journal prior to being
written into the main file system.
ordered This is the default mode. All data is forced directly
out to the main file system prior to its metadata being
committed to the journal.
writeback Data ordering is not preserved - data may be written into
the main file system after its metadata has been commit-
ted to the journal. This is rumoured to be the highest-
throughput option. It guarantees internal file system
integrity, however it can allow old data to appear in
files after a crash and journal recovery.
"You can still loose data, such as the contents of a document you were editing but had not saved".
Well unless you've got some special sort of memory, you're going to lose everything you (or the application) haven't saved, whatever type of file system you use.
OpenBSD uses softupdates (still in development, need an fsck still). Right here. The linked papers are useful reads.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
There is no penalty for games. Games only read. The performance hit is for mass file creation and renaming and so on.
News for Nerds. Stuff that Matters? Like hell.
Oops, they have!
Well, we all know Apple's just "embracing and extending", they don't ever submit any of their extensions to the IETF and release that code, right?
wrong, and wrong again!
I'd rather have a plain old UFS filesystem that IS case sensitive than HFS+journaling+whatever.
Then... use one. You can create and mount UFS filesystems with OS X. You can even install the OS on a UFS filesystem, but legacy software often depends on features of HFS/HFS+. So if you don't have any legacy apps, you can run an entire OS X system on UFS.
I write in my journal
MOST Linux distros have a couple of Journaling file systems. ext3 being the most common. JFS (from IBM) and XFS (From SGI aka IRIX) are others. I use JFS on my home partition and ext3 everywhere else with naru a performance hit....actually, ext3 has been out for almost 1 years and a half with Kernel 2.4.10
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
Unless Apple is caching its graphics to disc before displaying them, it wouldn't make a different in your "eye-candy processing power".
Thats a 15% hit in disk performance, not system performance.
A journaling filesystem does not "provide corporate Mac sites with a new, historical view of their data"; all it does is increase reliability.
huh? Linux has quite a few journaling filing systems, in particular it has the rather fine ReiserFS. In the next kernel series, RFS 4 will be out, which seriously kicks ass from what I've been seeing. In particular it has very high performance, esp for small files. XFS has attributes too.
I am thinking about getting a Laptop with OSX so I was wondering how OXS compares to Linux.
A quick comparison:
But the most important of all, OS X is proprietary and has all the lockin nastyness you'd associate with Windows, Linux is free. Nuff said.
Hmm... I disagree.
/usr/local/ mounted with a 3 gig UFS partition, but not problems with that in the last 3 weeks.
I use my tiBook as my unix dev server for our server platform. though, we deploy onto unix, I can do 99.9% of the operations on my tiBook and as I work 50% from my home office, it's a perfect fit.. I always have my dev server with me.
I have managed thus far to achieve a few crashes, mainly due to a resource leak with file handles and also a strange bug in Java. I have had my software crash litterally thousands of times in development cycles. I have had to hard-reset because of a hard lock w/the quartz engine....
Anyway, I -abuse- this laptop (which I am typing on right now). It's has been an absolute champ. I haven't had anything go corrupt, and never had an error i couldn't recover from.
Note, that I did re-partition my drive and stuck
My G4 tower (466) has been a mysql and pgsql database server and a host of my personal webserver for almost 2 years now. It survived moving over-seas twice and my abusive MP3 harvesting tools to newsgroups *gasp, I know*.
Anyway, to say that a 'real user' will experience problems is utter bullshit. I don't know what's going on with your stations but we have 5 people on the team using G4's (some laptop+tower) and we never have problems.
Imagine that you have a library, and a librarian is filing away new books. When she is done filing them, she puts entries into the card catalog downstairs for the new books. The card catalog represents a filesystem's metadata.
Now imagine that the librarian falls out of a 2nd story window into a dumpster and is carted away before she finishes filing the books and updating the catalog. You have no idea what books were filed; you have to perform an exhaustive search of the library to ensure that the card catalog is correct, which takes a long time. This was fsck before journaling.
Servers with large amounts of disk space cannot afford extensive fsck times after a crash. It can take hours.
Now imagine that the librarian keeps a small notepad of the books that she is filing, and when she meets her sticky end, the new librarian can read the notepad, check and verify the new entries, then update the card catalog to a consistent state. We assume that the notepad is updated before the book is filed, so if we have an incomplete notepad entry, the librarian died and the entry can be disregarded. The notepad corresponds to the journal in a journaling file system.
It takes time to write a journal, so journaling filesystems will always be at least a little slower than non-journaling equivalents, design improvements aside.
Most journaling filesystems will only guard the card catalog (metadata). Some, such as VxFS and ext3, can also be made to journal the books (data), but performance goes down because so much more goes through the log.
Another feature to look for in journaling filesystems is dynamic inode creation. ext3 does not have this feature - you can only have so many card catalog entries, and when you exceed them, you can't add any more new books. XFS, for example, can create new inodes on the fly as long as you have disk space.
For Sun people, it is always a surprise to find that Sun's UFS does journaling (you don't have to buy Veritas VxFS), but you have to turn it on with an option in /etc/vfstab.
I know of one AOL Grandma who has only one troubleshooting strategy: she power cycles her iMac whenever she has a computer problem.
Doug Moen
I have written a truly remarkable program which this sig is too small to contain.