Slashdot Mirror
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.
...when you pry HFS+ from my cold, dead hands.
No, wait. Give me that.
But what do I know. I'm just looking for anonymous gay sex.
Is this an entirely new journaling system or one based on an existing (BeOS) journaling system? Won't there be performance and stability impacts from basing it on HFS+ instead of a more modern framework? Is is possible to compile one of the existing *BSD journaling systems on OSX/Darwin (I haven't heard of anyone with success in this matter)?
what other important features has OSX that Linux has not. I am thinking about getting a Laptop with OSX so I was wondering how OXS compares to Linux.
...to Switch! This was about the last major gripe I had with Mac OS X. We already have an encrypted file system. However, no matter how I have abused my Macs in the past, I have never had filesystem corruption with HFS+. I constantly forget to unmount my iPod and yank it off the firewire cable. Mac OS X grips about the possibility of filesystem corruption but so far, so good. Others mileage may vary and I wouldn't do it during a write.
Strange women lying in ponds distributing swords is no basis for a system of government.
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.
Though it will cost you 10% to 15% performance penalty
This refers to hard disk access time penalties, not an overall 10-15% reduction in the performance of your computer. You wouldn't notice the difference.
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.
I wonder if that stated 10-15% performance hit
is with or without journal on a separate disk.
I'm surprised no one has brought this up yet.
Ben "You have your mind on computers, it seems."
At least this shows Apple's serious with courting the tech-savvy audience. Before, the reason to go with Apple was out of preference for the UI... and that was it. OS9 was ungainly and unstable. With OSX there're now true geeky reasons to want a Mac. No more being ashamed of coveting the rainbow apple! I want protected memory/journalling fs/unix multiuser/process stability/gnu tools/etc ... and an interface that looks like i can eat it for dessert!
I predict that it will become faster with time.
Just looking at how OS X itself has progressed in speed from Public Beta (slug with brick tied to it), to 10.0 (slug), to 10.1 (average lazy human), to 10.2 (average lazy human drinking strong coffee), I expect that by 10.3 this technology will not give nearly such a performance hit.
And heck. Don't like the speed hit? Turn it off.
But what do I know. I'm just looking for anonymous gay sex.
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.
do you get an "Elvis has left the building" message?
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!
A new and cool feature would be a file system that maintained a Weblog...
Today I stored my user's tax return...what a piece of crap...he actually expects the IRS to believe that he donated 40,000 to the MDA?...I think I'll just switch a few numbers around and drop a hint to the audit hotline
Yeah, that could be good...where's the SourceForge project for this?
I use FAT32.
The diskspace used by the journal file in NTFS and this new filesystem can be put to much better use.
Ya, like all of the fucking backups you need to keep your data safe. On that 80Gig disk, no less.
Fuck
All
There
is what we used to call the FAT filesystem, and for good reason. No security, no recovery. You work for Peter Norton, any chance?
Get a clue, bud - journaling file systems were integrated with _all_ modern OSes for a reason. Namely, big gain, near zero cost.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
Disk Read Failure: The King is dead.
-----
jonathan barket
The critical differences for me are that Apple stuff Just Works, Really Really Well, OS X is a Unix, and Apple seems to be philosophically opposed to Digital Rights Restrictions.
Whether or not they'd be like this if they were in a monopoly position is up to debate, but Apple is currently a far less evil company than Microsoft. Instead of putting roadblocks up for me, the Mac makes most things I want to do far easier.
I don't think beige boxes are the target market for this. I'm imagining this running on a RAID 5 setup with Xraid later this year. I wouldn't use this on just one little drive at home...
As for disabling it, read the article. It's not even on until you get into Terminal and turn it on.
Giving up my change to use my 2 remaining mod points in this
thread by posting...
> If it takes a 10-15% performace hit that is significant on
> older hardware.
That explains why it's switched off by default, I expect. Some
people in some situations will be glad to take a 15% performance
hit for the benefits of journaling, _if_ the journaling is of the
level of quality that is claimed (i.e., as good as in BFS). The
article says (at the end) that Apple wouldn't comment, so they
may still be weighing that, as well as the performance issue.
IMO, it's good for them to give people the option. If nobody
turns it on, there's no real downside. If some people _do_ see
fit to turn it on, presumably that's because they value it.
Cut that out, or I will ship you to Norilsk in a box.
"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.
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.
The kjournald process is flushing the journal. This doesn't mean (AFAIK) that your filesystem is only up-to-date as of the 5s interval that kjournald last ran. When the system reboots without unmounting properly, it replays the journal to get it as up-to-date as possible (up to the last transaction that was fully written to the journal). The point of flushing the journal every 5s is to limit the size of the journal and therefore the time it takes to replay it on reboot. And quick reboots are the point of journalling.
A huge fraction of technical (and high-spending) PC users who might switch know exactly what Slashdot is.
It would be awesome: "... I'm Rob Malda, and I run Slashdot.org"
Do I see an Apple "switcher" ad featuring CmdrTaco in the near future?
There are 01 kinds of cars in the world. The General Lee, and everything else.
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.
On servers, despite its popularity, journaling makes much less sense: there are better ways to recover from failures, and the performance hit really does matter.
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 think this will also benefit the AOL Grandma crowd. Can you imagine their reaction upon booting up with a dirty partition and having to go into single-user mode and repair a filesystem?
Nazi SYS5 init architect:
Mein Furher! Ve needen maken startup of system harrrrrder to administrrrrate. Ist too eazy now. Even girly non-blue eyed non-Aryans can administrate serrrrvers now.
SVR4 Nazi Furher:
Ja wohl!!! How can we skrrrrrrew de administrrrrators?
Nazi SYS5 init architect:
split ze starrrrtup scripts, makingkt dem more komplicated.
Umm, I don't think that happened. I find SVR4 style easier. Every service in it's own seperate file. Ever try to start a system server on BSD by hand? It's harder than you think. In SV$ land, I can take any server down by running a kill script and restart it by running its startup script. hell, even FreeBSD has a SVR4 style init directory (granted, only for a single run level now). And if it's all that hard, just make
Hmm, Berkeleyness of Berkeley software, who knew?
FreeBSD (maybe all {Free,Net,Open}BSDs) uses SoftUpdates, which in some ways is better than journalling, depending on what you want.
It turns out that what people really want is a non-MS desktop that actually works. Most people over the age of 14 don't give a rat's ass about the ideological aspects at all.
Boobies never hurt anyone. - Sherry Glaser.