Slashdot Mirror
Ext4 Advances As Interim Step To Btrfs
Heise.de's Kernel Log has a look at the ext4 filesystem as Linus Torvalds has integrated a large collection of patches for it into the kernel main branch. "This signals that with the next kernel version 2.6.28, the successor to ext3 will finally leave behind its 'hot' development phase." The article notes that ext4 developer Theodore Ts'o (tytso) is in favor of ultimately moving Linux to a modern, "next-generation" file system. His preferred choice is btrfs, and Heise notes an email Ts'o sent to the Linux Kernel Mailing List a week back positioning ext4 as a bridge to btrfs.
Couldn't they come up with a better name than "BuTteR FaSe?" I know I can't be the only one who read it like that. Call it anything but that.
So it incorporates compression by vowel ommission? Brllnt!
Unless ZFS has patent issues, why not just work on having ZFS as Linux's standard FS, after ext3?
ZFS offers a lot of capabilities, from no need to worry about a LVM layer, to snapshotting, to excellent error detection, even encryption and compression hooks.
I would like transparent, administrator controlled, versioning. Modified a word document and saved it in place? root can go back and get the old version ( and, alternatively, the user can. root could disable this functionality ).
The pieces are in place, it's doable, just someone needs to program it.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
No I did not. Thanks to you, now whenever I am eating or drinking at the computer, everything will taste like land-o-lakes butter faces now. Bleh!
Once you start despising the jerks, you become one.
Nice, but does it murder your wife?
This is what it would be like, if the majority of people were athiests.
ATHIEST KID: Mom, I'm going to go fuck a hooker.
ATHIEST MOM: Okay, son.
ATHIEST KID: Afterwards, I'm going to go smoke pot with my friends, since it's "not addictive."
ATHIEST MOM: Okay, come home soon!
The athiest kid leaves the room. The father comes home from work several minutes later.
ATHIEST DAD: Hey!
ATHIEST MOM: Hi, honey! I'm pregnant again. I guess I'll just get another abortion, since "fetuses don't count as human life."
ATHIEST DAD: Okay, get as many abortions as you want!
ATHIEST MOM: Oh, and don't go in the bedroom.
ATHIEST DAD: Why not?
ATHIEST MOM: There are two gay men fucking eachother in there.
ATHIEST DAD: Why are they here?
ATHIEST MOM: I wanted to watch them do it for awhile. They just aren't finished yet.
ATHIEST DAD: Okay, that's fine with me!
Suddenly, their neighbor runs into the house.
ATHIEST NEIGHBOR: Come quick, there's a Christian outside!
ATHIEST MOM: We'll be right there!
The athiest couple quickly put on a pair of black robes and hoods. They then exit the house, and run into the street, where a Christian is nailed to a large, wooden X. He is being burned alive. A crowd of athiests stand around him, all wearing black robes and hoods.
RANDOM ATHIEST: Damn you, Christian! We hate you! We claim to be tolerant of all religions. But we really hate your's! That's because we athiests are hypocritical like that! Die, Christian!
THE END
Scary, isn't it?
Butter FS? Are you kidding me?
Here is your first official list of jokes. Please contribute.
1. You're still running ext4? I can't believe it's not ButterFS!
2. But will it run on toast?
3. Will fsck be renamed to butterknife?
4. If your system overheats will your filesystem melt?
5. If you use ButterFS too much, will it turn into FAT?
6. If you leave ButterFS on your volume too long, will your hard drive start to reek?
7. Will the next version of ButterFS be called GoatButterFS, just like the next version of Leopard is Snow Leopard?
8. "Tough" notebooks will never have their hard drives formatted with ButterFS, because if you dropped them, they would always land hard drive down.
9. When you submit your dead ButterFS hard drive to a data recovery centre, will they have an intern lick it to get the data off instead of putting it under a read head?
These are getting kind of desperate -- your turn now.
Honestly, what is it with FOSS and crappy names? (looking at you, gimp)
Great for playing "Hello Kitty! Adventures"
Anybody want my mod points?
Butter Fase probably intended as Butter Face.
Sounds like "But Her Face" as in: She has a great body, but her face...
A Linux article on Slashdot!?
Why not? It's a good analogy for FOSS after all. Great software, robust and all, but her face...
Starbucks, Harbuckle of Breath.
Something like ZFS immediately comes to mind... but is there some generally accepted definition of what makes a file system "next generation"? TFA doesn't say, and I hate to diminish anyone's efforts here, but the new features in ext4 (according to wikipedia) aren't much to write home about: higher precision time stamps, larger volumes, larger directories, faster fscking. These may be worthy accomplishments but they are incremental improvements, not anything new. Or did I miss something?
You're right. BTRFS is really silly. I recommend that the shortened form be ButtFS.
I think it reads more like "Bit Rot" filesystem, perfect for 20 year old EPROM chips.
I saw that and couldn't help but think, are they trying to make a filesystem based on the B-tree concept?
Personally, I like "BuTt RiFfS" better.
buttered only
"Couldn't they come up with a better name than "BuTteR FaSe?" I know I can't be the only one who read it like that. Call it anything but that."
I read it as:
BeTteR FileSystem
I guess we'll have to part was :P
Good, strong file-bearing hips!
DRM: Terminator crops for your mind!
that outta make a good marketing strategy
fifteen jugglers, five believers
Yeah. You are.
ZFS duplicates a lot of functionality that belongs outside of a filesystem.
Very true.
It wouldn't be possible to duplicate RAID-Z with LVM.
Also true.
And the features which could be duplicated, couldn't be done nearly as well without a little more knowledge of the filesystem.
The real problem here is that we're finding out that generic block devices aren't enough to do everything we want to do outside the filesystem itself. Or, if they are, it's incredibly clumsy. Trivial example: If I want a copy-on-write snapshot, I have to set aside (ahead of time) some fixed amount of space that it can expand into. If I guess high, I waste space. If I guess low, I have to either expand it (somehow, if that's even possible) or lose my snapshot.
A filesystem which natively implemented COW could also trivially implement snapshots which take up exactly as much space as there are differences between the increments. But because of the way the Linux VFS is structured, this kind of functionality would have to be in a single filesystem, and would be duplicated across all filesystems. Best case, it'd be like ext3's JBD, as a kind of shared library.
A humble proposal: We need another layer, between the block layer and the filesystem layer -- call it an extent layer -- which is simply concerned with allocating some amount of space, and (perhaps) assigning it a unique ID. Filesystems could sit above this layer and implement whatever crazy optimizations or semantics they want -- linear vs btree vs whatever for directories, POSIX vs SQL, whatever.
The extent layer itself would only be concerned with allocating extents of some requested size, and actually storing the data. But this would be enough information to effectively handle mirroring, striping, snapshotting, copy-on-write, etc.
It wouldn't be universal -- I've said nothing about the on-disk format, and, indeed, some filesystems exist on Linux solely for that purpose -- vfat, ntfs, udf, etc. Those filesystems could be done pretty much exactly the way they're done now. After all, the existence of a block layer in no way implies that every filesystem must be tied to a block device (see proc, sys, fuse, etc.)
But I think it would work very well for filesystems which did choose to implement it. I think it would provide the best of ZFS and LVM.
I haven't actually been seriously following filesystem development for years, so maybe this is already done. Or maybe it's a bad idea. If not, hopefully some kernel developers are reading this.
Don't thank God, thank a doctor!
The volume and snapshotting functionality in ZFS is quite different from that in the Linux kernel.
When you have the LVM and RAID inside the file-system, you can easily do things like do a RAID rebuild of *ONLY* the data the file-system is using. So if you have a 5TB file-system with 100MB of space in use, you can do a RAID rebuild in a few seconds instead of several hours.
Ditto for the snapshots. Linux's LVM implements snapshots, but you have to allocate storage to the snapshots specifically, where in ZFS you can use free space inside the file-system volume for snapshotting.
For example, one ZFS system I have currently has 229 snapshots on it, and I don't have to worry about any of them running out of space unless the whole file-system runs out.
So, saying that these are features that should be implemented outside of the file-system is easy to say, but loses a lot of the functionality you gain if they are all closely tied together.
Sean
rgtfo..
It could also be read as BeTteR File System.
I read it as "BitterFS" :)
So, cue the jokes.
How is this filesystem? Like Btr.
"ButterFS"--they're afraid to claim it is "BetterFS"?
That would mean we'd still have to wait for bstFS.
I guess if it's going to stay "butterFS", there ought to a special loopback driver so that you can put the butter on top of something else: brdFS.
Then look no farther then NSS ( Novell Storage Services ).
It is Open Source, you get the full source if you download SLES.
It has more of the desired features then anything else on the block right now.
This should be the default file system for Linux. It has years of very heavy duty R&D behind it, it is pretty much completely de-bugged and ready to rock.
Hey KID! Yeah you, get the fuck off my lawn!
I read it as BeaterFS and wondered if it was too soon for ReiserFS jokes.
ParkayFS?
Butter.
This is something that has bothered me about open source in general for a while now, why is that there is so much fragmentation? So many wheels that are being re-implemented for the sake of being re-implemented? I agree that a new file system that supports all the new features of btrFS and ZFS are required, at the same time I don't understand all of this duplication. ZFS has some features that btrFS does not have, and vice-versa, why not spend the time developing a hybrid of the two, thereby massively increasing the usability and stability of both products, or rather, of just one product since the time and effort would only be but into the hybrid.
If it is possible for Nvidia to use binary blobs for their graphics cards, it should be possible to use CDDL code with a compatibility shim in the Linux kernel. All this duplicated effort could instead be focused on one project, thereby having an all around better file system. btrFS has just recently started coming into fruition, would that time not be better spent improving ZFS?
It seems that license issues are the only thing that is causing all of this trouble in the first place. As a user of a system I don't want to spend valuable time testing all the various file systems, I also don't want to have to support all of the different file systems that are available. With a project as large as Linux, and the amount of file systems that are available, how can it be guaranteed that the file system I ultimately go with has been properly bug tested, has had the proper code review done, and is not going to be shoved aside for the next new shiny file system that is introduced? As an end-user (and I hereby don't mean the home user group) I want stability. FreeBSD gives me UFS2, I know I can depend on it, I know it will still exist tomorrow, and I know that it is still being looked at for performance improvements and improvements in general, ZFS has recently been imported and is will exist for a long time. OpenSolaris gives me UFS, and ZFS, I know it is going to be around, I know it is going to be improved. Linux gives me XFS, JFS, ext2, ext3, ext4, ReiserFS, Reiser4, and now btrFS. Depending on my workload and who I ask I get told to use different file systems on Linux. Individually testing each and everyone would be time consuming and error prone, instead of all of these different file systems make one unified file system.
For that reason, and that reason alone I use FreeBSD 7.0 and Solaris 10 on my servers. Stability is a good thing, I need some way to relay to my clients that there is a reasonable time schedule for new releases, that what they are storing their data on right now is going to be around tomorrow, and that it is stable, that it has been time proven and tested. Linux can not provide that at the moment.
cat
I'd like to know why Ted Tso and others are working on ext4? Even when ext4 is feature complete it will be the #3 filesystem in linux in terms of features and scalability behind xfs and jfs. I'd like to know what Ted Tso and others grudge against xfs and jfs is because they basically wont even acknowledge those filesystems.
btrfs does have some nice looking features, its basically a gpl rewrite of zfs.
The weakness with linux is in the LVM or EVMS layer. They both suck in that they are not enterprise ready (ie multi TB filesystems, 100+ MB/s sustained read/write) in that they cause unexplained IO hicups, lockups and kernel panics. LVM/EVMS certainly work fine for Joe Blow's HTPC, or a paltry 100GB database but they fall down when under serious load.
This is the problem with open source. Certain areas, like filesystem development attract all the developers, and other areas like LVM/EVMS are seen as busting rocks and nobody wants to work on them. The results is we get a plethora of second rate filesystems (ie ext4) and a buggy LVM/EVMS layer that nobody wants to work on.
I think of it more like BART Filesystem
Yeah maybe, but I was thinking about a dual meaning: "Bitter" could also be thought as "someone who sets bits". Or maybe it means the devs like their beer bitter. Or maybe BTRFS could be translated as "BetterFS"... BTR-60 and BTR-80 are also Russian armoured personal carriers so maybe this means BTRFS is solid enough to be used in heavy Russian military equipment...
Have you considered that modern CPU have more then 2 privilege levels?
Bloke, it is Canadian...
Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
NIH
Je ne parle pas francais.
How primitive. Those Linux guys are savages!
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Nice legs, shame about the boat race.
Disclaimer: The opinions and actions of the US Gov't are in no way representative of those held by this author or its ci
This is the internet, it's never too soon.
ext2 beat them all, hands down. Then for GNU Linux came cfs, hpfs, jfs, ext3, xiafs, reiserfs, onto ext4fs, and you know what was still easier to tune and outperformed all others in data retention and speed? You guessed right: ext2. Everything else is slowly becoming convalescent by needing complex database code that only makes stability no better when not a NAS mirror node, and worse is software writers depending on file system constructs through libraries outside ANSI C or worse by abstracting standard IO with said database. Doesn't anyone remember what simple functionality made Linux great, and now the same take it into a dark age of complexity to market their *ise Service route?
Couldn't they come up with a better name than "BuTteR FaSe?" I know I can't be the only one who read it like that. Call it anything but that.
Missed the point! It's BTR FS, the bullet-proof filesystem for Linux!
They feed him. They put a roof over his head.
They even bathe him.
He might as well devote himself to filesystems.
While btrfs looks quite cool, I'm even more interested to see whether http://tux3.org/ will go anywhere. Let's hope both will materialise and mature soon.
It hurts performance. You're doing RAID/LVM stuff
on disk blocks that could be empty. Wasting effort
on unused bits is stupid.
It endangers data. RAID/LVM stuff isn't normally
transactional. (there is no journal or log)
You can handle booting with a dead disk, and you
might be able to handle a disk dying at some
arbitrary point in time, but you can't handle
disks that mangle your data in interesting ways.
Do you have any reference regarding the LVM/EVMS issues? I'd be interested to find out more about that.
If you want a versioning file system, go use VMS for a while. They've been doing it since at least the early '90s. Not sure if ADVFS has that feature or not, never got a chance to use Tru64.
Actually, the versioning file system FILES-11 originated in 1980 or perhaps earlier. At least, I recall that it was standard on RSX systems in 1980, and supported file versioning (albeit with wierd "directory" organization: UIDs like [310,54] were used instead of directories).
File names could have a semicolon and version number attached, or if no version was specified then the highest version was implied. This led to the need to clean up old versions regularly, with a command such as:
PIP LB2:[310,54]*.TSK/PU:3
which would purge all but the three highest versions of each task file in [310,54] on the library 2 device. More explicitly, single file versions could be deleted with a command such as:
PIP LB2:[310,54]F11ACP.TSK;4033/DE
which would delete only version 4033 of the named file.
The PIP commands acquired saner aliases in VMS, and the organization of the file system was somewhat improved. But the versioning was there already in 1980 in FILES-11 under RSX-11.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
The weakness with linux is in the LVM or EVMS layer. They both suck in that they are not enterprise ready (ie multi TB filesystems, 100+ MB/s sustained read/write) in that they cause unexplained IO hicups, lockups and kernel panics. LVM/EVMS certainly work fine for Joe Blow's HTPC, or a paltry 100GB database but they fall down when under serious load.
LVM has been rock-solid for me with a ~7TB and 2 2TB ext3 filesystems (24 500GB disks) over the course of a year and a half. No problems migrating extents all over the place when I needed to swap disks in and out. Almost identical to HPUX in functionality, but without the sizing constraints.
But, when I tried xfs for kicks I found out that a 7TB filesystem means you need 7GB of RAM to fsck it - impossible on a 32-bit system, I also had a week where I it all went in the shitter because I ran free-space to zero and started getting OS panics and data corruption.
I'm definitely considering jfs for the next generation, my main complaint with ext3 has been ridiculously slow deletes and fsck's. Problems I have read don't exist with jfs.
When information is power, privacy is freedom.
While I do see the point in file-system research and advancement, to me the usefulness of a 'better' hierarchical file system is limited by the traditional API used to access the data stored thereon.
I'd like to efficiently store data direct to a block device in a different structure. I want to have support for (multi-user) transactions and to replace the concept of a 'file' with a mapping from one (arbitrarily long) sequence of (arbitrary) bytes to another... and to be able to read back pairs of byte-sequences by specifying domain ranges.
From a low-level implementation perspective, I can't imagine that this is wildly different to a hierarchical file system with efficient directories (relaxed to allow the zero byte as part of a filename) but I can't find any work that has been done on such a facility.
If such an alternative "filesystem" were to be implemented and have a reliability on a par with existing linux filesystems... it could revolutionise data processing.
If anyone is aware of such a project, I'd be very interested.
Maya Rudolph uses Linux.
Squirrel!
Was a good analogy... Maybe.
Compiz shot us way out front in the looks department.
xfs is useful, but xfs should be used with a UPS. Sure, the filesystem metadata is safe on power failure, but files with outstanding uncommitted blocks at the time may be zeroed out when the system comes back up.
The exact failure mode involves a file's metadata being updated before its data blocks are committed. You hit this problem frequently when doing the write-new-file-then-atomic-rename dance if you don't fsync the new file before the rename; most applications neglect that technically-required fsync because things just work on non-xfs filesystems.
In other respects, xfs is excellent. I just wish it were more robust against dataloss.
there needs to be a "-1: Fail" moderation
7TB filesystem means you need 7GB of RAM to fsck it
7GB of swap will do, it doesn't need to be RAM. And yes, 32-bit is a no go.
I've switched to jfs on pretty much all of my systems and I've had very little reason to complain. I had been using xfs, but saw fs corruption in several instances.
You think that's bad? The file system check command is buttfsck!
This kind of thing has been a huge obstacle to Linux on the desktop. The lack of a stable kernel API tells hardware manufacturers to stick with Windows. Even the past few years, with the introduction of Vista, has been less disruptive than every year is on Linux.
a 7TB filesystem means you need 7GB of RAM to fsck it
That's what SHE said!
== Jez ==
Do you miss Firefox? Try Pale Moon.
How about something really catchy and descriptive like, "Ogg VobisFS"
Well, almost.
Anyone else remember Novell Btrieve (B-tree based database library)?
The scary thing about Btrieve was that each month the rate of growth of the known/fixed bug list seemed to be increasing, although the product itself seemed pretty stable in our use at least.
More tarty make-up, than actual looks, imo. Looks is a clean intuitive interface the responds quickly. Wobbly window frames and cubic desktops are just lipstick and eyeshadow. i.e. attention-seeking flash. Of course that's what some go for and it's good to be able to apply it if you want it. But I would liken it to real looks.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
BeTterFS? Better filesystem? I don't know how much you've been drinking but... ;)
Here be signatures
I can't believe it's not better.
To fix problems in the filesystem, would you have to run ButtFSck?
anyone happen to know if the driver from fs-driver.org will work with ext4? It works with 2 and 3
Exactly. I couldn't even imagine where Linux would be right now if it weren't driven by a bunch of egotistical nerds clamoring for their own implementation of something rather than incorporating someone else' extremely capable and far more mature existing implementation.
Similes are like metaphors
But crikey, goes all night without stopping. None of that Windows "I'm so sorry, this has never happened to me before, honest."
http://rocknerd.co.uk
I just choked.
http://rocknerd.co.uk
All I want to know is if I can fsck this BtrFS.
For me, it's "do I have to fsck her all the time?"
I used to do that, and then I got a UPS instead and switched back to pure ext2. The performance hit from journalling is simply too high to tolerate. A decent UPS (pretty much anything made by APC) will prevent the crashes in the first place, solving the problem completely and without any unnecessary overhead. With UPS prices being as low as they are, there is no excuse for not having one, so I think that journalling will become obsolete in some near future.
Our industrial UPS (which is orders of magnitude more reliable than any APC product ever made) recently exploded, burnt, and shorted out the entire building's power. It spiked thousands of volts through the protected equipment and destroyed a half-dozen servers. The fire was fierce enough to cause our fm200 system (halon equivalent) to dump, which put out the fire before the main battery bank was breached.
This was the first time I've ever seen an UPS bigger than a Chrysler fail, but I've seen dozens of failures from those crappy little APC units. At one time I had a stack of burnt-out ones in my basement (I used to salvage the batteries for cash).
If your disaster survivability plan depends on any single piece of hardware never failing, it's no good. Offsite backup is your friend.
Er, that limitation of XFS has long been fixed. Now 4GB of RAM is good for something like a 100TB file system. If you have a larger file system then it would not be unreasonable to have more RAM.
The only issue with XFS is the inability to shrink it at the moment.
You hit this problem frequently when doing the write-new-file-then-atomic-rename dance if you don't fsync the new file before the rename; most applications neglect that technically-required fsync because things just work on non-xfs filesystems.
I don't know much about filesystem design, but isn't this just a bug in the journalling? Does it apply equally to all of the reasonably recent versions of xfs?
As an application developer, I'm certainly sympathetic to anyone who avoids fsync in certain situations -- depending on the details, it can certainly make things more sluggish. How much responsiveness to trade for how much security is a pretty individual thing.
I understand that Bennigans' will be changing all their servers over to Butter FS.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
It seems everyone has different experiences with different filesystems. My experience is:
- ext2/ext3 : Utterly failed to work on a 1 TB filesystem I was setting up. Would not even format. Doesn't matter anyway because the thought of running fschk on a volume that size is not appealing. On the "normal" sized setups I have had numerous filesystems totally obliterated due to corruption (and fschk often just makes the problem worse). Nowadays I only use it for boot partitions which are basically read-only.
- ReiserFS3 : File corruption like mad. System freeze/crash, accidentally hitting reset switch, etc. anything like that caused many files to get corrupted. Sometimes just rebooting a machine would cause stuff to get corrupted. This was well after (years) it had been fixed up and was "stable". I gave ReiserFS a long tryout for several years but it really did suck.
- JFS : Unstable (kernel panics, etc). I have tried it a number of times over the years and it never seemed to get better. It has been probably 3 or 4 years since I last tried it though. Seemed very unstable every time.
- XFS : In the old days it used to use a lot of CPU/RAM but nowadays this is my primary FS. Fast, handles large filesystems no problem, no file corruption at all even in the worst system failures I have seen (including hardware failure). Lots of features and tools (but not perfect). I do have some gripes... Although it's better than ext3 in every way, it's still a bit slow when deleting extremely large files or large directories of files. Also, when the filesystem is close to being full the performance degrades rapidly. And finally, it's annoying that boot utilities can't work off an XFS partition (this one is stupid in my mind, a single tiny tweak to the spec would fix this).
We have an ~8TB JFS array used for shared storage of databases on our linux boxes, as well as for another smaller arrays used for VM's and general file serving duties. Bitchin' fast even with small files, no extra latency incurred by using ACL's as you get with ext3, very fast to format and fsck (ever tried this on a 2TB ext3 array? Painful!), lowest CPU utilisation of any filesystem we tested, frags up alot less than ext (yay for extent-based filesystems), ridiculously quick deletes, equal to XFS in speed at dealign with large files with less overhead at the same time. Only real disadvantage is that it doesn't support shrinking, but that wasn't considered a big downside for us.
Never tried LVM on anything that big though, ours is just stacked hardware RAID10 stripes across a starburst of cheap SATA drives. Use it on a 3TB LVM at home though, not had any problems with it - but that's comparatively zero load.
It wasn't popular initially since it wasn't supported by Redhat, but we have less issues with the JFS partitions than we've ever had with the ext3 ones (yeah yeah, famous last words ;)) - besides, we use CentOS boxes for these anyway (yeah yeah, more famous last words...).
Most underrated filesystem available for Linux IMHO, and those of you who've used it on AIX will already know its awesomeness and how comparatively gimped the linux version really is :) Bottom line: we use JFS on any disc-based IO that's performance critical, and ext3 everywhere else in order to attempt compliance with corporate support ;)
Moderation Total: -1 Troll, +3 Goat
I want to know who in their right mind would even trust ext4 the brand new kid on the block over say JFS/XFS that have been round the block many times.
ext4 is frankly an utter waste of time. The whole ext2/3/... series is well past it sell by date and going for another upgrade is a pointless waste of effort, that would be better spent fixing any issues with JFS/XFS (the primary one being the inability to shrink them).
Bitter yeah. But it never killed anyone.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I'd like to know why Ted Tso and others are working on ext4?
Because he wants to. Some people play softball, some people write fs code. It's because they derive some satisfaction or enjoyment from it.
Those of us who run Ted's code (remember, he's the linux capabilities guy) benefit greatly from his activities, because he's smart and capable. But really, he's doing it for himself; he's a self-actualized human being.
Not to persuade you away from JFS (To each their own), but ext4 fixes the slow deletes (Extents free up a lot of metadata over ext3's method, especially for large files) and the long fsck's (fsck only checks the parts of the FS that are in use and can be run while the fs is online), from what I've read.
... And so it comes to this.
(speaking of poor names...)
But she's such a GIMP!
I've been running a multi-TB fileserver for a few years now. It is ext3 on LVM on RAID5 (MD).
My only complaint the whole time has been the block size in ext3. If ext3 had 1MB blocks, I would be VERY happy.
See that "Preview" button?
You call Windows "extremely capable"??
Just because it CAN be done, doesn't mean it should!
Actually OS/2 used ring 2 for privileged DLLs and VMS used 4 rings for all sorts of stuff - ever since the VAX that is because even the VAX had 4 rings. But then VMS is 10 years younger then UNIX and offers a lot of stuff UNIX still hasn't got.
So there are operating systems which uses more then 2 rings.
Martin
Wobbly window frames? Cubic desktops? I use Compiz and I have neither of those things. Just because a desktop can be tweaked to appeal to people with no taste doesn't mean that it's inherently attention-seeking. You might as well judge cars based on what happens to them in "Pimp My Ride".
I've fscked a 12TB (mostly full) XFS volume with 2GB of RAM in ~10 minutes with the newer versions of xfsprogs. If its going that slow and taking that long, you're well past due for an update. They've made some really amazing improvements.
Oh jeez, I know this is just asking to be modded down, but I really don't care. Yes, Windows is the most capable desktop operating system. Prove me otherwise.
Similes are like metaphors
Personally, I'd rather move to IBM's JFS, but if you gotta chase the next "dream FS"...
Sour grapes IMO.
Well it does support tail packing. Draw your own conclusions.
deserved to fsck.btrfs /
Maybe the GPP intended a read-only mount, as a diversified file system is the intent of stability and performance. /usr to a peculiarly advantaged filesystem. Tell me, who has the base system directories constantly in read-write mode, as though they just can't decide what software they want on their computer? Some people have already decided and installed their user applications and libraries; we aren't shuffling everything around like mad XP, OSX, and muVista. Tell me who is faster in read-only? Now consider why one needs journal outside their /home (better to symlink that to the actual, /usr/local/home or /usr/home)? What keeps people from remounting their system root fs to read-write but only to move system binaries and libraries (maintenance), and then just remount read-only when done?
Notice how ext2 is fastest, but none rememered to mount their / in "ro" (read-only) and mount their
Now consider why one needs journal outside their /home
Yeah, good point, I mean who the fsck would ever want to write to somethings like /var/logs?
not a fancy automated shell to abstract the essential liberty you inherently have available, then subdivide the / filesystem and keep journal file systems only on data that needs it.
/ ext2 ro /var jfs rw /tmp jfs rw /home reiserfs rw /usr ext2 ro /usr/share reiserfs rw /usr/local ext2 ro
Well, of'course /tmp should be a ramdisk and maybe /var as well, but when do you need somthing outside /home to be read-write except when installing software? /home and various /usr/ and /usr/local/ mountpoints are all that need the necessary journal and mirroring because that's where the certain data is being held. Holding the entire system on a / filesystem in read-write is asking for a roothack to knock you out of the water after the blackhole sun sucks out all the crew and passengers.
IMHO, if you need to depend on a UPS, that doesn't bode well for the filesystem. How is it any better than an ancient filesystem like UFS/Ext2 (mounted async), if it doesn't do a good job with integrity? What's "excellent" about XFS?
A UPS can't prevent a system crash either, so you need a decent FS.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Let me know when a tiling window manager has compiz support. Then we'll talk. Until then, XMonad wins for usability.
OS X is at least as capable, seeing as how it can run Windows as an application. Linux can also, though Windows can run Linux as an application now. Neither Windows nor Linux can run OS X as an application.
There is no problem when linking CDDL code with code under a different license, so the changes that need to done to the kernel could be done under gplv2 with ZFS as a module. That shouldn't be a problem since they do the same with nvidia already. Wouldn't it be great if the user had access to a compatible filesystem?
Talking bout compatible Filesystems:
ZFS is supported under MacOS, FreeBSD and Solaris. NetBSD and DragonflyBSD support are planned iirc. Btrfs and ext4 are supported under Linux only. Finally there is a filesystem which is adopted by a wide range of operating systems, it's open source, it's advanced, powerful and very easy to manage, supports transparent compression and encryption(coming soon), integrates nfs and cifs management and so much more..... and the only major operating system that DO NOT implement it are windows and linux?
I've used linux for the last 12 years, but this license foo that is going on right now, which is keeping very useful open source software (zfs and dtrace) away from me, really soured my linux experience. I can live with a few less drivers for hardware i will never ever use, but i won't renounce features that save me hours and hours of work just because some guys don't like another open source license or chooses to spread FUD over those features (Zemlin.. I'm looking you're way)
Regards,
Bjoern
OK, no modern operating systems for modern processors use more than 2 rings.
So you consider a 39 year old system more modern then a 28 year old system? Ok, Unix had more face lifts done so if you look at the GUI of a current Unix it look more fresh.
When was the last time OS/2 or VMS made a new release?
VMS - "Latest stable release OpenVMS 8.3-1H1/ October 25, 2007". It is still used for high integrity systems. There are quite a few tools in the high integrity world which the low integrity world considers long dead. And you know what: If the low integrity world would sometimes have a look at those tools they might learn how to create less bug ridden systems.
Though I'll give you that VMS has a lot of stuff that Unix simply can't ever have because Unix was designed off an entirely different basis.
More importantly: If UNIX do get some of those hight integrity features bolted on (ACL, extended attributes, POSIX capabilities spring to mind) they are generally not used - usually because of backward comparability concerns.
I remembers Brams dismissive reply when the communities asked for ACL support in Vim. If the standard editor (most system don't have a dedicated vi any more) won't support ACS - who does - who will.
This is why I like my Mac - at least Apple does use all those nice new extras.
Martin
Not as far as I know and actually with the so called "hypervisor mode" we now have 5 rings of operation in x86 architecture:
http://en.wikipedia.org/wiki/Ring_(computer_security)
Well each their own. I did say that if it's what you like then fine. But my opinion is that most of the compiz stuff is more about attention seeking and showing off than it is about real substance. Hence my likening it to make-up and bling, rather than natural beauty which comes before both. You can turn it on or off, so it's good that it exists. And it does look cool. But I've got it turned off on mine. I pay more mind to what's underneath.
Regards,
H.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
OS X is at least as capable, seeing as how it can run Windows as an application.
You mean it can run Windows in a VM with limited functionality, specifically in the graphics department. OS X is slow and bloated, but thanks to common perceptions most people believe this not to be the case. I for one, had a MacBook Pro that I dual booted Windows on, and I can testify to this fact 100%.
Similes are like metaphors
Which is perfectly OK as long as all Linux users still have the choice as to which software they choose. Making that choice an easy one for users who don't know how to compile stuff would also be a very nice Linux advancement, and even that can deal with fragmentation, as long as the fragmentation rests on top of some of the most common standards.
Promote true freedom - support standards and interoperability.
Right, OpenOffice.org started looking so much more better thanks to Compiz.
I am not devoid of humor.
No, OOo looked good before compiz.