Tru64 Unix Advanced File System (AdvFS) Now GPL

melios writes "In a move that could help boost the scalability of Linux for grids and other advanced 64-bit multiprocessor applications, HP has released its Tru64 Unix Advanced File System (AdvFS) source code to the open source community. Source code, design documentation, and test suites for AdvFS are available on SourceForge."

Comments

Sheesh...

[adolf]

Allow me to be the first to say: It's about fucking time.

Re:Sheesh...

[Anonymous Coward]

+1

With the release of advfs, it makes the lack of zfs for linux a bit less painful.

Re:Sheesh...

[Anonymous Coward]

In your face ZFS losers!!! The penguin is unstoppable. We have the best coders who can do stuff like this. M$ and $UN are more dead then B$D!!! lol

Re:Sheesh...

[snoyberg]

M$ and $UN are more dead then B$D!!! lol

Yes, but does netcraft confirm it?

Re:Sheesh...

[hostyle]

Well no, but there is way to get your wish: http://www.abyssandapex.com/200710-wikihistory.html

Re:Sheesh...

[Anonymous Coward]

Hey those $s in MS and SUN are telling me that you're making parallels between Sun and Microsoft.

Did Sun buy ZFS from the guys that made QDOS?

Re:Sheesh...

[Winter Lightning]

In your face ZFS losers!!! The penguin is unstoppable. We have the best coders who can do stuff like this. M$ and $UN are more dead then B$D!!! lol So why didn't the penguin coders do it? AdvFS was developed by Digital as piece of closed source; aren't you rewriting history to suggest that it came from the Linux community?

Declarations/health warnings:
  1) I work for Sun and I rather like ZFS :-)
  2) In a former life I also used AdvFS and thought
            it was a good filesystem; probably the best general
            purpose FS around until ZFS.
  3) Integrating AdvFS into Linux and exercising it for prime
            time won't be an overnight job; perhaps several years
            before it can be deemed trustworthy.

Re:Sheesh...

[Bert64]

But how does advfs compare to zfs?
Advfs is certainly a lot more mature, having been around on digital unix, later tru64, for many years...

Re:Sheesh...

[rootooftheworld]

dumbass, bsd is not dead, mod parent down

Re:A new open file system?

[PalmKiller]

Who?

What's the point?

[tjstork]

Is there some reason to pick this file system over any of the other 100 file systems you can get for Linux?

Re:What's the point?

[cephah]

This one is -- advanced, so it must be good, right? Right?

Re:What's the point?

[eclectro]

because it's not a "killer" filesystem?

Re:What's the point?

[bsDaemon]

i dunno... no wifi, less space than ZFS. lame!

Re:What's the point?

[Cyberax]

AdvFS is comparable in features to ZFS - it has snapshotting, intelligent striping and mirroring, dynamic resizing, etc.

In short, there's no comparable production filesystem in Linux right now. There's Btrfs from Oracle, but it's in deep alpha.

Re:What's the point?

[Vectronic]

Comparison Of File Systems

Although its missing from some of the charts...

AdvFS

And that page is rather limited in information.

Re:What's the point?

[Anonymous Coward]

Nah dude, SGI's xfs (in vanilla Linux since ages now) can do all of those tricks, too.

Re:What's the point?

[Anonymous Coward]

except that xfs is a local filesystem, genius...

Re:What's the point?

[diegocgteleline.es]

No, it can't. XFS has not the concept of "storage pool" that ZFS and AdvFS have. It doesn't have ZFS/AdvFS-style snapshots. XFS is also a journaling filesystem, unlike ZFS (AdvFS however is a journaled filesystem - and even then, the journaling modes of advfs allow to configure a much better data integrity than ZFS)

Re:What's the point?

[Paul Jakma]

It doesn't have the Merkle tree and the associated error-detection properties of ZFS though.

Also, AdvFS (or PolyFS, as I could swear it was called in the beginning - though Google can't seem to any record of it) had a pretty bad reliability record in its earlier days, at least bad enough that its unreliability still was mentioned in DEC Open Systems Support when I visited there in 2000.. (by which stage Tru64 clearly was on life-support). ;)

Re:What's the point?

[raddan]

If you don't need to know the difference, then no. But there are plenty of people who have specific requirements, and I'm glad that Linux supports them. E.g., we pay to have our Linux machines use CVFS (StorNext) and associated daemons, because we require its features. A GPL'ed CVFS suite would be awesome, but I can understand why Quantum wouldn't want to do it.

Re:What's the point?

[mhall119]

Hopefully this will make Sun re-consider licensing ZFS under the GPLv2.

Re:What's the point?

[joib]

So is ZFS, genius...

Re:What's the point?

[Cyberax]

No. XFS is a multimedia-oriented filesystem, it was designed to support multithreaded streaming with guaranteed access times. It works well for these use-cases.

But it doesn't work well for a lot of other use-cases, though. Hence, the current development of Btrfs.

Re:What's the point?

[Just Some Guy]

Hopefully this will make Sun re-consider licensing ZFS under the GPLv2.

Doubtful. GPLv3 is too nice a license for them to reject just because Linus is being bullheaded.

Re:What's the point?

[Znork]

it has snapshotting, intelligent striping and mirroring, dynamic resizing

Eh, exactly which feature is unique? Snapshotting, striping, mirroring, resizing, encryption, etc, all of it can be done through the device mapper stack.

I have situations where I don't want any filesystem at all on the mixed chunks (shared iSCSI block devices, for example), others where I want partial mirrors, parts crypted, parts remote-synced, etc. Mixing block device, volume management and filesystem together in my opinion, simply bad engineering. There are far too many assumptions about what people usually do so you end up with something suitable only for exactly what the designer had in mind, and worse, sometimes completely unsuitable for what people actually do.

Having run both AdvFS and ZFS, I _vastly_ prefer the layered approach of ext3/LVM/md/etc.

there's no comparable production filesystem

Yes, well, try actually running ZFS in production for a while with any kind of odd load (and some not so odd loads at all). Sometimes things just aren't all they're hyped up to be.

Filesystems are one part of most systems where 'exciting' isn't the most desirable feature.

Re:What's the point?

[Nutria]

Is there some reason to pick this file system over any of the other 100 file systems you can get for Linux?

AdvFS is a clustered FS.

Re:What's the point?

[Anarke_Incarnate]

ZFS is an excellent filesystem but with some serious bugs that are poorly documented. I will admit I have not played with it in a while, but when I did, there were a considerable number of growing pains and kernel tunables that needed to be tweaked to get it to play nicely. The read block size is 128K by default, the ARC buffer size is ridiculously designed to assume that you want to cache data, filesystem syncs run to check integrity even if you have disk integrity checks on the SAN, etc.

Re:What's the point?

[profplump]

Hear hear! I think snapshots, mirrors, stripes, encryption, compression and resizing are all very useful things. But I'd like my file system to stick to managing files and use the volume and block layers to provide those features under any file system.

Re:What's the point?

[larry bagina]

Why would they want to? Under the CDDL, *BSD, Apple, Microsoft, (pretty much everybody except linux and HURD) can use the ZFS code without being virally infected. Sun gets back any improvements and bug fixes.

Under the GPL, Sun can't enjoy any bug fixes or improvements made to the code.

Re:What's the point?

[Cal Paterson]

Linus was bullheaded about the licence originally, but he isn't being bullheaded now. He can't change the kernel to be GPLv3 compatible after the fact.

Re:What's the point?

[ScrewMaster]

Hear hear! I think snapshots, mirrors, stripes, encryption, compression and resizing are all very useful things.
Thank you! Finally someone wrote "Hear hear!" instead of "Here here!".

Re:What's the point?

[TeknoHog]

Having run both AdvFS and ZFS, I _vastly_ prefer the layered approach of ext3/LVM/md/etc.

As a unix user, I generally prefer a layered approach. How did something like ZFS manage to come from unix people for unix, rather than from our friends in Redmond?

Re:What's the point?

[master5o1]

I have a Merkle tree growing in my backyard.

Re:What's the point?

[master5o1]

Nintendo?

Because Microsoft is generally our 'enemy'.

Re:What's the point?

[cheesybagel]

Not just Linus being bullhead. He shot himself in the foot by sticking to a fixed GPLv2 license. AFAIK to relicense to GPLv3 would require contacting all authors to see if they accept the change of license. Which is how many hundreds of people?

Re:What's the point?

[Burdell]

There are advantages to having some things integrated at the filesystem layer instead of at the block layer. For example, creating a snapshot of an AdvFS fileset uses the free space in the fileset to store the changes, instead of having to have an otherwise unavailable chunk of the block device reserved in case I want a snapshot (and I can create snapshots of multiple filesets simultaneously without having a bunch of chunks of reserved space). The combination of file domains and filesets in AdvFS is useful; you can have multiple (otherwise distinct) filesets share the available space in a file domain. This is useful for using a large chunk of space but having distinct user/group quotas, inums, etc.

AdvFS also has been the basis for the TruCluster single system image clustering OS for years. In a TruCluster setup, you have one root filesystem that is shared throughout the cluster (vs. most cluster setups where each cluster member has its own root/OS filesystem and just shares some of the data). Combined with inode versioning, this allows rolling updates of the OS; our two member cluster was up for about 4 years until we had two separate failures at the same time.

AdvFS has its warts (just like all filesystems and OSes for that matter), but it is very useful in its places. It is also a very proven system (having been around in production use since about the same time Linux first started, with one major version update in around 2000 IIRC). I don't really see how some of the good and useful things you can do with AdvFS can be done without some type of "layering violation" or two-way communication between the VFS and the block layer.

Now, if someone would just port AdvFS to Linux so I can migrate my data to ext3/4 a whole lot easier (no matter how good it is, AdvFS and Tru64 are a dead end).

Re:What's the point?

[OrangeTide]

Let's just write a new OS instead. Would be easier than getting 100 geeks to agree on anything as political as software licenses.

Re:What's the point?

[SanityInAnarchy]

I think snapshots, mirrors, stripes, encryption, compression and resizing are all very useful things. Got it.

But I'd like my file system to stick to managing files and use the volume and block layers to provide those features under any file system. How, exactly, should the block layer provide resizing or compression?

I mean, yes, you can do snapshots -- clumsily, as you have to set aside space for it (can't just stuff it into free space on that volume) -- and that's inherent in the nature of the device-mapper. There's no way for DM to know which blocks are free -- that's the filesystem's job.

And yes, you should be able to do compression at the block level -- or at least, read-only compression, as we see on livecds these days. How would you add write support? If you tell the filesystem it's on a 10 gig device, and it's really on a 5 gig device, what happens when I write 6 gigs of high-entropy data to it? If you tell the filesystem it's on a 5 gig device, I won't be able to write 6 gigs of low-entropy data (text), because how would the block layer tell the filesystem it has more space?

Now, I get it that ZFS is too monolithic. I do. But the current volume/block layers are not sufficient to get some of the more interesting features of ZFS, without creating a filesystem that's as monolithic as ZFS. (There's no technical reason you couldn't port ZFS to Linux.)

At the very least, we need more layers. Maybe an extent layer, to start with. I'm actually going to start developing exactly that -- prototyping in Ruby (with FUSE). It'll be fast enough for my purposes, and if people really want speed, they can port it to the kernel -- I just don't feel like writing C.

I'm thinking an API something like this:

id = extents.store(some_string)

Obviously, allow for streaming, multiple devices, etc, but you get the idea. You could layer them, too -- compression would be a layer you can slip between any backend device (block layer, network store, RAM, whatever) and any filesystem, in pretty much the same way you can slip encryption between any block device and any filesystem today.

Re:What's the point?

[Macka]

It doesn't have the Merkle tree and the associated error-detection properties of ZFS though.

Also, AdvFS (or PolyFS, as I could swear it was called in the beginning - though Google can't seem to any record of it) had a pretty bad reliability record in its earlier days, at least bad enough that its unreliability still was mentioned in DEC Open Systems Support when I visited there in 2000.. (by which stage Tru64 clearly was on life-support). ;)

It was pretty flakey around Tru64 v4, but got a major re-write for Tru64 v5 which cleared up the problems and made it very stable after that. Today, it's the most stable filesystem I've ever used. And you're right about the Poly stuff. There was a marketing drive which fortunately didn't last very long where they tried to brand it as the Polyserve filesystem, then it got changed. Even Polyserve was an improvement on its birth name, the MegaSafe Filesystem. You can still see remnants of that in the Tru64 kernel config file: its the options MSFS line that triggers inclusion of AdvFS into the kernel. The word MegaSafe also crops up all over the source tree too. Go take a look ;-)

Re:What's the point?

[Ilgaz]

Ask it to your Telecom Operator. They probably rely on it on a very mission critical server, usual on telecoms. HP/UX and Tru64.

They opened their own filesystem in GPL V2, not V3 even. If you don't have anything to do with a filesystem which is tested in real life scenarios for years in various organisations, you can ignore or just appreciate.

Re:What's the point?

[The name is Dave. Ja]

Thear, thear. Don't get all in a knot over spelling.

Re:What's the point?

[tietokone-olmi]

Of course you can combine LVM with XFS, JFS or ext3 and have the same damn features. You can have shrinking with reiserfs, and dynamic enlarging with any of these filesystems.

Jeez, I don't get why people fap so hard over ZFS. Is it the FreeBSD crowd with their infectious frothing at the mouth again? Or macfags with their BSD AIDS?

Re:What's the point?

[jgardner100]

Can you expand on this ? I.e. given that ZFS has copy on write, the intent log and checksums everything, what can AdvFS do to give it better data integrity ?

Re:What's the point?

[tietokone-olmi]

Well, I guess that's what one gets for distrusting the FSF.

Linus is apparently vulnerable to close friends whispering things in his ear. Take Larry McVoy for instance: far as I know, mr. Torvalds supported BitKeeper until McVoy terminated the free license; that is to say, Linus was perfectly fine with all the competition-restricting license details and the use of proprietary software to manage a Free Software project. And if you remember, back in 0.x and 1.x days, things like sound card drivers for Linux used to be proprietary, for-pay software!

I wouldn't be surprised if his original rejection of the "or later" licensing model had come from some other "friend" of his. Influence is a curious thing after all, especially in the case of a person whose principles and strength of character are lacking.

Re:What's the point?

[Anonymous Coward]

By release 5.0 of Tru64 AdvFS reliability was very good. The versions released with the 4.0 stream were not quite there yet.

Re:What's the point?

[Anonymous Coward]

"He can't change the kernel to be GPLv3 compatible after the fact."

Yes he can. He even said how (while I can't find the reference on Google, lame me). Basically, he would do a public announcement: Hey, folks, I'll go GPLv3 in six months; whoever that have something to say, do so or be silent for ever. By the way, that's how he went from GPLv1 to GPLv2 quite some years ago.

Re:What's the point?

[Anonymous Coward]

I worked at HP just after they merged with Compaq (2002/2003) in a site which had been part of DEC before Compaq bought them. We used AdvFS quite heavily and so did some big customers with very big disks and generally it seemed ok.

I'm not sure it provides anything over Zfs though, but still nice to have a choice. The main advantages I seem to remember were volume management allowing you to add and (I think) remove disks from a volume. Kind of like LVM but with a slightly easier to use interface.

Re:What's the point?

[Anonymous Coward]

"Under the GPL, Sun can't enjoy any bug fixes or improvements made to the code."

And, taking apart your surely knowledgeable opinion, what part from either GPLv2 or GPLv3 would make such "bug fixes or improvements made to the code" unaccesible to Sun?

But, why I'm wasting my time with somebody that calls himslef "bagina"?

Re:What's the point?

[complete loony]

ZFS has a lot in common with a journalled filesystem, I'd almost be tempted to call it one. But instead of using a separate journal to record and playback changes to other meta data, the journal *is* the meta data.

Re:What's the point?

[Fweeky]

Erm, ZFS is layered; you can put UFS or ext2 or.. whatever, on top of a zpool, complete with RAID, checksumming, copy on write, etc (features which all fit well together in that layer). I don't really see how it's any different from LVM, except zvol's happen to be able to do a bit more between the devices they consume and the devices they provide.

Re:What's the point?

[Anonymous Coward]

Testify, brother.

Hey, try AOE instead of iSCSI. I switched over a couple of years ago and it's fantastically cheaper for roughly the same thing (granted, iSCSI is more mature but AOE is a stronger design). AOE is unroutable, but this is hardly an insurmountable problem in real-world applications.

I agree with everything else you said!

Re:What's the point?

[gladish]

I get it... since ZFS and AdvAFS are "journaled" and not "journaling" they can restore your data before you even write it. They should port this technology to their inkjets.

Re:What's the point?

[pdp1144]

It can generate the message, "Converting space into time" When it is reorganizing the file system structure to optimize how much data you and put on the file system; over how quickly you can access the data. We still talk about this message at work; and we haven't seen it in over ten years. We had the data center evacuated for safety when we first saw it.

Re:What's the point?

[pdp1144]

I seem to remember something funny when writing floating point numbers with fortran code (I think). It couldn't read it back correctly. It was a show stopper.

Re:What's the point?

[FishWithAHammer]

Well, I guess that's what one gets for distrusting the FSF. Not to troll, but why trust the FSF with the ability to relicense your code as you see fit? The relative value of the GPLv3 is, in this case, irrelevant to Linus's line of thinking.
 
And seriously--BitKeeper worked for Linus's needs. He's a pragmatist, not an idealist.

Re:What's the point?

[Anonymous Coward]

It was mandatory when you used TruCluster, I suppose it got some "cluster awareness" in it.

Re:What's the point?

[TheQuantumShift]

I would think the point of this would be to examine the code and if theres good stuff in there, merge it with other codebases. Of course that does defeat the "I'll write my own filesystem! With Blackjack! And Hookers!" mentality that seems prevalent...

Re:What's the point?

[IgnoramusMaximus]

The poster you are replying to:

... a person whose principles and strength of character are lacking.

You:

He's a pragmatist, not an idealist.

It apparently escaped you that these are pretty much one and the same thing.

An idealist, for example, is a politician who would try to stick to his beliefs even when sniper's bullets are whizzing next to his head. A "pragmatist" is a politician who will take all the lobbyist money he can get his paws on (after all this is the "reality" of politics, surely?), promise everyone "centrist compromises". "bridging the gap", "reaching across the isles" etc to get elected and then do everything that his most powerful and rich friends ever wanted.

In short "pragmatist" is the Polite Society's code word for "spineless, unprincipled opportunist".

Re:What's the point?

[Paul Jakma]

You can use ZFS volumes as block devices (e.g. for iSCSI), with your own FS on top of it. You don't lose that ability..

Re:What's the point?

[mvdwege]

Naah, it's the Unix(tm) greybeards who finally have something that is newer than 1991, so that they can now look down upon Linux as both Not Real Unix(tm) and technologically inferior.

Mart

Re:What's the point?

[larry bagina]

And, taking apart your surely knowledgeable opinion, what part from either GPLv2 or GPLv3 would make such "bug fixes or improvements made to the code" unaccesible to Sun?

If sun releases ZFS under GPL, any 3rd party modifications will also be GPL. Sun can't integrate it back into (CDDL licensed) Solaris due to the viral nature of the GPL. The CDDL doesn't have a viral problem.

But, why I'm wasting my time with somebody that calls himslef "bagina"?

Because you're an idiot.

Re:What's the point?

[Mr. Fahrenheit]

As an aside, Oracle also has OCFS2 which is intended for clustering. Still needs some work, but is really pretty robust.

Re:What's the point?

[skulgnome]

One doesn't have to trust the FSF with relicensing of their code. After all, the licensing terms are, in the end, "GPL version [current] or (at your option) any later version published by the FSF". Thus the original license also stands, should a future revision prove unacceptable.

In exchange one avoids falling into the "well I'd like to go with version 3, but can't" trap.

It's a good deal even if the FSF were, right now, composed solely of crooks and bastards.

Re:What's the point?

[peawee03]

Agreed. After an accidental power loss to several drive bays on our SAN, our 30-TB ZFS pool didn't want to import anymore. Spent a week debugging the kernel to discover *where* it was breaking, and then writing something to munge the on-disk data structures until the "self-repair" utilities could take over. Apparently the uberblocks (ZFS version of superblocks) got munged pretty much everywhere, and the label headers and uberblocks weren't matching up. Any FS that claims perfect data security to the point of not requiring a fsck program should never require the error message saying "you're boned, flatten and restore from backups," which is the only error message I've ever seen it give.

Also, it's slow in creation and handling of small files. Our system (approx 100 users on a 45 node HPC cluster) takes about an hour to unzip the gcc source (takes like 10 minutes on my MacBook). Huge files get the full throughput of the SAN, but small ones take forever.

Lastly, ZFS doesn't let you remove volumes from the pool, or add singly into a RaidZ.

We're most likely going to figure out how to migrate back to Linux/LVM/XFS, and not even think about AdvFS. 'Exciting', indeed.

Re:What's the point?

[wkcole]

it has snapshotting, intelligent striping and mirroring, dynamic resizing

Eh, exactly which feature is unique? Snapshotting, striping, mirroring, resizing, encryption, etc, all of it can be done through the device mapper stack.

AdvFS has a less concrete feature: maturity. It has been under development with the pressures of a commercial "enterprise" customer base for 16 years. Whether that maturity is going to be relevant in a port to other OS's is an open question.

I have situations where I don't want any filesystem at all on the mixed chunks (shared iSCSI block devices, for example), others where I want partial mirrors, parts crypted, parts remote-synced, etc. Mixing block device, volume management and filesystem together in my opinion, simply bad engineering. There are far too many assumptions about what people usually do so you end up with something suitable only for exactly what the designer had in mind, and worse, sometimes completely unsuitable for what people actually do.

Having run both AdvFS and ZFS, I _vastly_ prefer the layered approach of ext3/LVM/md/etc.

AdvFS is layered on top of a LVM, it just hasn't always been obvious that the two are not one thing. I have not worked with ZFS enough to know whether there really is severability between its layers, but I don't see where one would really want to make the cut for ZFS anyway.

That said, your general point is valid to some degree, in that one integrated stack of software to handle all storage devices and present a filesystem to apps isn't always the right choice, and well-defined layering can give you more flexibility for some uses. On the other hand, an integrated stack like AdvFS or ZFS (and to some degree IBM's JFS and VxVM/VxFS) can be a lot easier to manage for many situations.

Filesystems are one part of most systems where 'exciting' isn't the most desirable feature.

AMEN!

Re:What's the point?

[rootooftheworld]

sadly, i think hes right. BTW i like vi best.

Re:What's the point?

[rootooftheworld]

agree. if, for instance, i have small hard drive on which i keep the OS and software, and a bigger one for most of the stuff i get from the internet, what do i do with ZFS? besides, i dont know how good the raw performance specs are, which are more vital to a SOHO/mediacenter/desktop PC than esoteric administering options.
somebody got any reliable stats for it?

Re:What's the point?

[rootooftheworld]

performance=?

Re:What's the point?

[rootooftheworld]

mod parent +1 genius

Re:What's the point?

[Znork]

I mean, yes, you can do snapshots -- clumsily, as you have to set aside space for it

Well, not that much, lvm snapshots are copy-on-write, so you merely need to store the delta.

If you tell the filesystem it's on a 10 gig device, and it's really on a 5 gig device, what happens when I write 6 gigs of high-entropy data to it?

Technically, we already have that problem on one level in the filesystem layer; sparse files. I dont know the internal mechanics of most filesystems, but I'd expect that knowing the exact size of the underlying device would not really be necessary; remaining space free would be more important.

For a really ugly hack you start with 'actual size with 100% entropy', then you could resize to keep free space in front of used space as compression makes extra space available in your block device, then call resize2fs or similar api call (I said ugly hack :) that will format the new space in front of writes.

Conceptually it's not impossible. It would, of course, be a pita if you then start deleting data and replacing it with higher entropy data, as that would start causing the device to shrink (back to the uncompressed size)... so you'd have to hack the filesystem to be able to actually handle shrinking too (and slap a huge warning label on it :).

Re:What's the point?

[masinick]

I recall the marketing attempt to call a bunch of stuff "Polyserve". I worked in Digital UNIX Software Engineering from 1995 until 1998 and the entire time I was there, the two projects were called AdvFS and Trucluster in the project builds and were commonly known by those names - but NOT Polyserve - in the engineering circles.

Re:What's the point?

[SanityInAnarchy]

Well, not that much, lvm snapshots are copy-on-write, so you merely need to store the delta. And you have to predict, ahead of time, how much space you need for snapshots. That's a bit like partitioning -- when was the last time you had to answer, at install time, exactly how much space you need for /var/spool?

It's nice to be able to do that, but I think most people would agree that it's much more convenient to just treat a hard drive as a big blob of space, and to use free space on that partition for the delta.

Also: copy-on-write is not uncopy-on-unwrite. If I save a 10 gig file, then delete it, there's still 10 gigs that was copied. The block layer doesn't know that it's all junk freespace now -- all it knows is that it's 10 gigs that physically differs between one copy and the other.

Similarly, if I make a massive change to a file, or a filesystem tree, and then revert it, not only is there no guarantee that the filesystem will put these blocks in the same place, but even if it did, I'm guessing dm-snapshot won't reassemble them.

I'd expect that knowing the exact size of the underlying device would not really be necessary; remaining space free would be more important. Fair enough. I don't think that changes anything here, though.

For a really ugly hack you start with 'actual size with 100% entropy', then you could resize to keep free space in front of used space as compression makes extra space available in your block device... Yeah, I thought of that. You already identified one problem with it. I've got another one: It's ugly!

After all, that's the major complaint against ZFS -- that it violates layering constraints, which offends people's sensibilities. And rightly so. But it's certainly better than what you've just described.

One more thing: If you seriously look at the above LVM-ish solutions, or anything else which involves messing around with device-mapper, it's going to cause a fair amount of disk fragmentation -- similar to creating a disk image for a VM. And when you've got a fragmented NTFS filesystem that's stored as a fragmented sparse file on ext3, well, let's just say that they don't cancel each other out -- you'll have to defrag them both (from inner to outer).

Re:What's the point?

[Znork]

And you have to predict, ahead of time, how much space you need for snapshots

I haven't actually ever tried to extend an lvm snapshot, as I've never had a use for it, but it would be trivial technically.

As snapshots tend to be used for things like backups and state-saves the problem tends to be framed by average rate considerations and storage time.

it's much more convenient to just treat a hard drive as a big blob of space, and to use free space on that partition for the delta.

In some cases, definitely. There are advantages to the approach.

it's going to cause a fair amount of disk fragmentation

Mmm, speaking of fragmentation, have you tried running ZFS for a longer period? If you think that would cause fragmentation issues, try running ZFS with high-write-transaction files like database files. Combine it with traditional SAN storage with huge cache blocks and you have a recipe for disaster. Copy-on-write tends to shred your files and destroy cache hit ratios.

I suspect they'll have to replace the 'change pointer on write' approach with an actual 'copy the old data on write'. Or simply offer an option to turn the COW off (is there one yet?).

Re:What's the point?

[SanityInAnarchy]

I haven't actually ever tried to extend an lvm snapshot, as I've never had a use for it, but it would be trivial technically.

Would it also be trivial to shrink the filesystem to make room for that snapshot? (Assume you aren't adding another disk.)

There are advantages to the approach.

Any disadvantages?

Mmm, speaking of fragmentation, have you tried running ZFS for a longer period?

Actually, I haven't run ZFS at all. Still, I suspect it would be easier to write a defragmenter for ZFS than for, say, ext3+lvm.

Re:What's the point?

[Anonymous Coward]

ZFS is transactional-based (like Reiser4) so it has the advantages of journaling without it. In addition to that, ZFS has checksums for every single block in the FS and it is verified on every read. I don't know if AdvFS has this too, but if it does not, then I rather trust ZFS.

Jordi Nadal

Cool

[Anonymous Coward]

The last file system I messed around with was absolute murder.

Re:Cool

[Anonymous Coward]

Hans? Is that you?

Re:Cool

[master5o1]

|Murder|FS

Re:Cool

[Anonymous Coward]

Nina? Is that you?

Re:A new open file system?

[east coast]

Hans Reiser is the developer of an open source file system but is currently jailed for murder.

Future gains

[Bandman]

I appreciate what they're doing, and I sincerely hope that it becomes a viable option within the next 6 months or so.

Cause I'm not using it for anything mission critical before that, anyway.

AdvFS

[MrMunkey]

I didn't know any of the details of what AdvFS was, so here is what Wikipedia has: http://en.wikipedia.org/wiki/AdvFS

Re:AdvFS

[BrentH]

Thanks. Still I have one question: does it do background filechecks (against a built-in checksum) like ZFS does?

Re:AdvFS

[X0563511]

That sounds like something the userspace would do, not really part of the filesystem.

Re:AdvFS

[BrentH]

The thing I like of ZFS is that it moves basically all file-related stuff to the actual filesystem, which makes sense to me, since that's why I have a filesystem. You basically don't need to know all these annoying details, or make checksum-databases yourself and check regularly. Still, the question stands.

I think I will wait...

[TimothyDavis]

...I hear WinFS will be in Win7...it should be legendary.

Re:I think I will wait...

[Anita Coney]

How come I never have any mod points when someone says something brilliantly funny?!

Re:I think I will wait...

[Anarke_Incarnate]

Nah, it got nerfed on the PTR. Now it is merely Epic, but it does not appear in game

Re:I think I will wait...

[Anonymous Coward]

Isn't that already in Vista?
no? I though it would.
or in service pack 1?
no?
Weird..

Probably won't be in W7 either.

Re:I think I will wait...

[Ilgaz]

If MS dared to do such changes, they wouldn't be in todays shape now. You know, that 1990s 16 bit junk written in Visual Basic must not have problem finding its data file.

Re:I think I will wait...

[jamrock]

...I hear WinFS will be in Win7...it will be mythical.

There, fixed that for you.

Re:I think I will wait...

[CoolGopher]

The question is, will it be possible to install DNF on it?

How many filesystems

[cybrthng]

Will linux need to make it "more enterprise ready"?

I think we see this claim to fame almost weekly yet it seems less and less reliance on OS filesystems and more reliance on SAN/Hardware/NAS/NFS storage.

OS filesystem improvements are welcome sight but the headline seems sensational as if all the other filesystems are actually holding adoption back. (which seems absurd)

Re:How many filesystems

[afidel]

What do you think actually powers many of those SAN/Hardware/NAS/NFS file servers, Linux of course. I really don't think the lack of file systems is holding Linux back, but having more of them that fit into more niches is sure to mean more adoption because Linux will be the hammer that fits the nail for those users.

Re:How many filesystems

[Thundersnatch]

Actually, most commercial SAN/NAS devices use a BSD-based kernel. NetApp, EqualLogic, etc. The GPL is a legal minefield that many commerical companies don't want to mess around with, especially when BSD-style licenses are available for most OS pieces. Lawyers cost too much.

Moreover, those commercial SAN/NAS that are Linux based typically only really use the kernel and some device drivers. The storage stack (file systems, volume management, clusterring, management interfaces, etc.) are typically proprietary "special sauce" technology and not open source at all.

Spiritual ancestor of ZFS

[mihalis]

I just had a quick glance through the wikipedia page on this filesystem http://en.wikipedia.org/wiki/AdvFS
and it seems to share a surprising number of features with ZFS
http://en.wikipedia.org/wiki/ZFS
For example, pools, snapshots etc.

Cool, license squabbling aside I look forward to the massively fragmented UNIX codebase slowly coalescing in this area.

Re:Spiritual ancestor of ZFS

[wkcole]

I just had a quick glance through the wikipedia page on this filesystem http://en.wikipedia.org/wiki/AdvFS
and it seems to share a surprising number of features with ZFS
http://en.wikipedia.org/wiki/ZFS
For example, pools, snapshots etc.

Not so much a spiritual ancestor of ZFS as a direct descendent of the primary spur for the creation of ZFS: the Veritas Volume Manager and File System, now commonly referred to as the Veritas Storage Foundation, and owned by Symantec. Sun developed ZFS after years of varying cooperative/competitive relations with Veritas that were not really customer-positive. VxVM/VxFS is a nice combo, in that it offers all of those nice features and lets you do things like migrate device groups (which can contain many volumes) from one machine on a SAN to another almost as fast as a umount/mount. "Enterprise" Solaris admins love Veritas SF for what it does, but have never liked its licensing and support status. ZFS is Sun's way of finally offering a fully integrated enterprise storage stack so that they are no longer hostage to another company's strategic choices. That's particularly helpful since the Symantec purchase of Veritas.

paging Mark Crispin

[ebunga]

I'd love to hear Mark Crispin's comments on this.

As a former Digital UNIX admin...

[Minwee]

...all I can say is that this would have been amazing news about ten years ago. Even five years ago it would have been pretty great.

Now? Well, it sounds like HPaq is just kicking it to the curb so it will probably be another year or two before anyone can beat it into a working filesystem for anything but HPucks. There is already no shortage of file systems that can do what AdvFS could do, so by the time it is ready for prime time prime time will have moved on.

Oh well. 1998 me is still pleased to hear this.

Re:As a former Digital UNIX admin...

[rahvin112]

Linux Weekly News has a comment from an HP developer indicating they aren't putting this out there so it can become a linux file system, but so that the lessons learned and parts of the code that are useful can be incorporated into one of the linux file systems of the future. I took it to mean, take our code and use whatever you can to make ext4 or ext5.
 
 

While it would be fine with HP if someone wants to "port" AdvFS to Linux or any other
operating system with a GPLv2 compatible license, this contribution is not intended to
"compete" with other existing file system projects underway in and around the kernel.org
development community.

Rather, our hope is that the algorithms, design documentation, and test suite now available at
the AdvFS site... and the active participation of HP engineers in various open-source file
system projects who have lots of AdvFS experience... will help to accelerate the inclusion of
AdvFS-like enterprise features and capabilities in next-generation file systems for Linux.

Re:As a former Digital UNIX admin...

[fm6]

Oh well. 1998 me is still pleased to hear this. Is 1998 you still on the line? Warn him that Star Trek: Insurrection really sucks!

Re:As a former Digital UNIX admin...

[youngdev]

you have a chance to impart some great information to someone of the past and you want to be a film critic? How lame.

Re:As a former Digital UNIX admin...

[Anonymous Coward]

That's all you'd tell your 1998 self?!?? I'd tell mine to invest heavily in the DotComs so he'd lose all his money...it'd be hilarious like that time someone told me they were my future self and that I should invest heavily in DotCom start-ups and I lost all my money!

Re:As a former Digital UNIX admin...

[Curlsman]

This was the filesystem that HP tried to port to HPUX and failed. They licensed Veritas instead.
I figured that the multithreading that I'd always heard worked so well in AdvFS/Tru64 was hard to port to the non-multithreaded HPUX kernel.

http://news.zdnet.co.uk/hardware/0,1000000091,39175690,00.htm
"It had initially planned to complete the migration of the TruCluster/AdvFS feature from Tru64 Unix to HP-UX 11i v3 in the middle of 2006."

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1214253121145+28353475&threadId=754760
"No TruCluster or AdvFS for HP-UX after all"

Re:As a former Digital UNIX admin...

[fm6]

This is Slashdot! "News for nerds, stuff that matters." What could matter more to a nerd than a bad Star Trek film?!

Re:As a former Digital UNIX admin...

[V. Mole]

it will probably be another year or two before anyone can beat it into a working filesystem for anything but HPucks.

Nitpick: it was never released with HP-UX. It was originally developed by DEC for their Unix product, originally OSF/1, currently called Tru64.

Re:As a former Digital UNIX admin...

[afidel]

It was pre-ordained, Insurrection was film #9 and all Trek fans know that the odd numbered films suck.

Re:As a former Digital UNIX admin...

[Tetsujin]

It was pre-ordained, Insurrection was film #9 and all Trek fans know that the odd numbered films suck. Except the first one.

Re:As a former Digital UNIX admin...

[dbrower]

This was the filesystem that HP tried to port to HPUX and failed. They licensed Veritas instead.

http://news.zdnet.co.uk/hardware/0,1000000091,39175690,00.htm "It had initially planned to complete the migration of the TruCluster/AdvFS feature from Tru64 Unix to HP-UX 11i v3 in the middle of 2006."

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1214253121145+28353475&threadId=754760 "No TruCluster or AdvFS for HP-UX after all"

It probably would have made the release too, except that it got canned after it was working.

It wasn't that HP failed to port ADVfs and trucluster to HPUX -- it was that they decided to stop it in favor of the other solution for arguably political and financial reasons. The people at HP in California were more than happy for the DEC people in New Hampshire to go away, even at the cost of licensing something that was no better than what they already owned outright, but would need to fund support for.

One wonders why they have bothered with this release at this point.

-dB

Re:As a former Digital UNIX admin...

[drinkypoo]

I'm pretty sure that this is just part of HP's exit strategy for the descendants of HP-SUX. They're already selling a lot of Linux. If they release it then the Linux community will almost certainly port it before Tru64's support EOL :)

Re:As a former Digital UNIX admin...

[Macka]

Spot on. If you download the sources, there's a README file in the advfs_gen3_src_v1 directory that says:

This directory includes the source code for a second generation
implementation of AdvFS, including the kernel modules, commands
and utilities.

This is the code that was ported to HP-UX. It is functionally
complete and went through fairly extensive functional and stress
testing. However, it should be considered beta quality and so
you may spot bugs. It is recommended that you review the
design documentation which is also available at this site
as it will guide you through the major subsystems.

This code will not build on HP-UX because it requires a
specialized build environment. HP-UX users are discouraged
from attempting to build or use this code on HP-UX as it will
not be supported by HP.

So it made the port ok. But it was a very lucrative deal between HP and Veritas over VxFS and their Cluster Silesystem that killed it. Money talks, and Veritas must've been crapping themselves that HP were about to walk away in favour of something better and home grown.

Though why anyone would want to use Veritas Cluster Filesystem considering the whopping price tag that comes with it, is beyond me.

Re:As a former Digital UNIX admin...

[gertam]

Exactly! It was all political why AdvFS was killed for HP-UX. A lot of really good work was thrown away because the HP-UX bureaucracy was too afraid of change and the ServiceGuard engineers were afraid that they would lose control.

Re:As a former Digital UNIX admin...

[pdusen]

Only if you count the special edition released decades later where the cutting was much improved so everything made more sense.

Re:As a former Digital UNIX admin...

[Minwee]

Which would be why the subject references "Digital UNIX", which was the name used by DEC after they gave up on OSF/1. Tru64 was Compaq's name for it, because they really hated words that were spelled correctly.

Of course if you know enough to nit-pick that then you would also know about what happened to it after the HP-Compaq merger and how the last surviving Digital engineers tried to weld useful features like AdvFS and TruCluster onto HP-UX only to have their projects canceled in favour of inferior and more expensive Carly-approved products.

So I won't explain that, given the lineage of the code, it's probably the stuff that was ported to HP-UX.

Re:As a former Digital UNIX admin...

[Anonymous Coward]

I figured that the multithreading that I'd always heard worked so well in AdvFS/Tru64 was hard to port to the non-multithreaded HPUX kernel.

HP-UX kernel is multithreaded since the 11.0 release (Nov 1997) - so it certainly can't be true that the port, assuming it failed was due to non-multithreaded HPUX kernel?

Re:As a former Digital UNIX admin...

[V. Mole]

It's both the Tru64 code and the "gen 2" HP-UX port. See SF download page.

And yes, I misread your original post as saying that AdvFS was originated in HP-UX. And yes, I'm well aware of how Compaq and HP screwed up DEC and pissed away some great technology. Of course, DEC did a pretty good job of screwing itself. Great engineers; incredibly piss-poor management.

Re:As a former Digital UNIX admin...

[Anonymous Coward]

This was the filesystem that HP tried to port to HPUX and failed. They licensed Veritas instead.

They didn't failed. They cancelled it before they began the work. It was a political decision, not a technical decision.

Re:As a former Digital UNIX admin...

[Anonymous Coward]

And yes, I'm well aware of how Compaq and HP screwed up DEC and pissed away some great technology. Of course, DEC did a pretty good job of screwing itself. Great engineers; incredibly piss-poor management. Posting anonymously because I have mod points and have used them on this Note...err Discussion. Sometimes the old DEC vocabulary returns in this kind of discussion.

DEC was an excellent hardware company that "accidentially" created great software. It was this hardware orientation/fixation that caused Ken and others to miss the fact that the industry was moving to commodity hardware. They tried to engineer a turnaround with the Alpha microprocessor. It was another great piece of engineering, they beat Intel to 1Ghz, but it was the wrong solution for the problem.

I have to wonder how many companies would be running Wintel environments if VMS and UNIX clustering had been available on commodity hardware in the 90's. There is still the question of how one could compete against Microsoft Office.

Re:As a former Digital UNIX admin...

[Grishnakh]

Wrong. Odd-numbered films only tend to suck; it's not an absolute rule. #3 wasn't that bad; I'd say it was better than #10. #10 sure didn't live up to the other even-numbered films. #9 wasn't that bad, either, also possibly better than #10.

Re:As a former Digital UNIX admin...

[fm6]

And everybody else knows that the even numbered films suck too!

Re:As a former Digital UNIX admin...

[fm6]

I haven't seen the "special edition", but I don't recall any problems making sense of ST:TMP. Nausea, however, was something of an issue.

Re:A new open file system?

[Urger]

Woosh

Good News Indeed

[Anonymous Coward]

I used ADVFS when I worked at DEC/Compaq. It is a really nice filesystem to use.
If the utilities are GPL's as well that is even better news.

Copying whole filesystems is a breeze as is copying filesystem trees and traversing over volume mount points ( ie not including mount points and all their files.)

It also gives you the ability to add/remove extra space to mounted volumes just like LVM does but IMHO without having to pre allocate it.
I would expect that some of the features may well be in EXT4 but I think that some of the Utilities could be made to use EXT4. /S
 

Re:Good News Indeed

[Lennie]

To answer your question, yes the utilities are user GPL-license.

Re:A new open file system?

[fm6]

Your sarcasm detector needs adjustment.

What's the obsession with filesystems?

[pschmied]

Certainly the Linux community doesn't really need to burn energy supporting a half dozen filesystems.

Talk to six linux admins and you'll get at least that many "every filesystem but the one I'm using sucks!" responses.

I'd gladly stand up for a lack of choice on the filesystem front. Pick one, make sure it's absolutely tested, make sure it supports a nice range of features.

Integrating a filesystem into another OS is a decidedly non-trivial task unless you just want to read files.

Thanks, HP, but I don't really want your no-longer-commercially-viable undead zombieware.

Re:What's the obsession with filesystems?

[CastrTroy]

But then you end up with the windows situation, where they only support NTFS (or FAT32, but who uses that). I don't think that any 1 file system is optimal for all tasks that one would want to use a computer for. People use computers for many different things. It makes complete sense to have file systems that accommodate the needs of different people.

Re:What's the obsession with filesystems?

[Anonymous Coward]

Exactly! They should just create a data structure and search algorithm with O(1) in all use cases.

Re:What's the obsession with filesystems?

[buchner.johannes]

Exactly! They should just create a data structure and search algorithm with O(1) in all use cases.

Linux has that, it's called /dev/null

Re:What's the obsession with filesystems?

[fm6]

Certainly the Linux community doesn't really need to burn energy supporting a half dozen filesystems. Or a hundred different distros. Yet they do exist.

Re:What's the obsession with filesystems?

[pschmied]

There are a lot of problems with Windows, but one sentiment I've never heard from any Windows admin is, "Gee, I wish I could reformat all my servers to use ext3."

Accommodating the needs of different people is great, but maybe we could accommodate the needs of different people with fewer superfluous choices which ultimately degrade the experience of all of said choices.

Which list of subtle filesystem problems will plague this new entrant into the Linux filesystem melee?

Windows effectively has Old FS and New FS. Apple has Old FS and is moving toward New FS. Solaris has Old FS and New FS. This isn't rocket science.

Re:What's the obsession with filesystems?

[pschmied]

Ignoring my grandmothers dying words advising me to not feed the trolls:

\sarcasm{Yes. This is precisely what I'm advocating.}

What part of "take one filesystem and make it good" warrants creating a strawman implying that I'm advocating for the total abolition of filesystems?

Re:What's the obsession with filesystems?

[Just Some Guy]

I'd gladly stand up for a lack of choice on the filesystem front. Pick one, make sure it's absolutely tested, make sure it supports a nice range of features.

Absolutely! I'm tired of having to pick different filesystems for flash and RAID-0/SCSI-320 volumes when their needs and abilities are obviously identical.

Re:What's the obsession with filesystems?

[CastrTroy]

Well, for Linux, I would say that you have Ext2, and Ext3, and that I guess Ext4, which will be the NewFS. If you aren't at all concerned with the differences, then just use EXT. I don't think a larger percentage of people run anything else. However, I think that having a system that assumes that there will be other file systems makes it a lot more flexible. Have you ever wondered why it's so hard to get good EXT2/3 support windows. It's specifically because it was written from the point of view, that nobody would ever want to use any file system, other than NTFS or FAT. So it's inherently hard to get any other file system working with it. If you work with the idea that some people may want other file systems, it doesn't end up as so much of a problem. I wouldn't want to run my servers using EXT3, but it sure would be nice to be able to mount my Ext file systems when I dual book into windows. I know it can be done, but all the solutions seem like big kludges, that only half work.

Re:What's the obsession with filesystems?

[pschmied]

We were clearly talking about general purpose filesystems here. Tell me again how AdvFS is any more applicable to flash than Ext3, NTFS, or JoeysBBQFS to the flash scenario you've outlined here?

While you're setting up strawmen, you forgot to include iso9660, UDF, 12 dozen network-based filesystems, half a dozen SAN filesystems, etc. etc.

Re:What's the obsession with filesystems?

[Kjella]

I must admit I never ventured past the ext* systems myself. I'm sure there'd be some improvements but on the other hand my system was working just fine. I do see that when you're trying to build a Linux server for a specific purpose, like say a database server then it's not all the same though. Msnu file systems show many people care about Linux filesystem performance, I'd be more worried if noone gave a damn. As for the perfect file system, it isn't built yet. Even the ZFS of much praise have trouble doing things like expanding arrays and such. And I'm not really complain if I end up with an "enterprise" class filesystem for free, just the way I got an enterprise OS kernel for free. I can think of worse ways to burn energy, and burn it does. But that's ok though, because I'd rather have people work on the things they do like rather than not working on the things they don't.

Re:What's the obsession with filesystems?

[Ant P.]

Integrating a filesystem into another OS is a decidedly non-trivial task unless you just want to read files. Write a FUSE driver. Problem nonexistent.

As for "too much choice", you may prefer to solve every problem with a hammer but I prefer a toolbox.

Re:What's the obsession with filesystems?

[Anonymous Coward]

Yes, but all the Linux admins are wrong because every Linux filesystem sucks. They should be using UFS2/soft-updates. ;)

Re:What's the obsession with filesystems?

[the_B0fh]

And that's why SuSE sucks, it still defaults to reiser. WHY?! And I'm not talking about the founder's legal issues. There are serious technical issues with reiser.

Re:What's the obsession with filesystems?

[Shimbo]

And that's why SuSE sucks, it still defaults to reiser.

It hasn't since about 2006 in the OpenSuSE versions. Their timing kind of sucked though, since the change was just after the stable Enterprise versions shipped.

Re:What's the obsession with filesystems?

[Xabraxas]

And that's why SuSE sucks, it still defaults to reiser. WHY?! And I'm not talking about the founder's legal issues. There are serious technical issues with reiser.

Suse doesn't default to Reiser anymore. They switched to ext3 a year or two ago.

Re:What's the obsession with filesystems?

[slittle]

That's just bullshit. The simplest reason is that writing file systems is hard work and Unix programmers have trouble enough managing a stable one even on their home turf, let alone a platform they know little about and often despise.

Of course, there's a difference between using alternate file systems on a non-bootable partition vs a bootable one, but that's mostly due to the required support of the bootloader - a problem that exists even on *nix. If you only want to access a shared partition from Windows, have you tried this?

And finally Unix file systems are written for Unix (POSIX) operating systems, so while Windows isn't dependent on NTFS as such, it's dependent on a decent ACL implementation (POSIX ACLs are crude and basically worthless with rare exception; believe me, I tried) and some other advanced features depending on what you're doing.

The fact that Windows isn't Unix is neither bug, nor feature, nor evil conspiracy; it's just what it is. Unix maps no better to Windows than to VMS or OS/390.

Re:What's the obsession with filesystems?

[Fnordulicious]

Actually, Apple isn't exactly moving from Old FS (HFS+) to New FS (UFS, née FFS) any time soon. HFS+ is basically required for the boot volume, and HFS+ has a number of features that don't exist in UFS (ACLs, file creation dates, extents, journaling, file type and creator codes, archive timestamps, etc.). That said, HFS+ certainly sucks for a number of reasons, but UFS is no replacement candidate. ZFS has a future with the Xserve and other server uses, but whether ZFS will ever be used on the Apple desktop remains to be seen; current suspicion is that it probably won't since ZFS isn't bootable on Sun machines yet.

Re:What's the obsession with filesystems?

[domatic]

Linux' extensive filesystem support has more than once saved my bacon when it comes to file recovery. In the form of a LiveCD, that filesystem supports makes Linux a veritable WonderWidget. I once even mounted an Amiga partition and copied off the files for a friend once. I regularly use Linux tools to restore and recover NTFS filesystems. If nothing else this will eventually mean you could use Linux to rescue old HP-UX disks.

Re:What's the obsession with filesystems?

[CastrTroy]

Explain to me why my Linux installation has no problem dealing with FAT32 and NTFS, but my Windows installation cannot handle Ext2 very well. That link you point to is good, and it seems like things have come quite a long way since I last looked at the abilities of Windows to access EXT, however there's still quite a few deficiencies. The predominant one is that it cannot access soft links. The fact that it doesn't support EXT3, with journalling, is a bit of a let down. Also, it seems to have problems with files that differ only by capitalization.

Re:What's the obsession with filesystems?

[slittle]

1) FAT is a very simple file system and the Linux implementation of NTFS is even less complete than ext2 is on Windows.

2) Linux users have a larger need/want to run FAT/NTFS than Windows users need/want to run ext2. Necessity, invention, etc.

3) Obviously, Windows is case retentive not case sensitive. As I said, Windows isn't Unix so Unix file systems aren't going to port well.

If anything, NTFS would port easier to Linux because NTFS is a much more feature rich file system than most *nix filesystems.

Re:What's the obsession with filesystems?

[Just Some Guy]

We were clearly talking about general purpose filesystems here.

No, we weren't, until it disproved your point. Nice way to move the goalposts, though.

Re:What's the obsession with filesystems?

[Anonymous Coward]

I once fell asleep in /dev/null during a magnetic storm and ended up in 1998.

Re:What's the obsession with filesystems?

[the_B0fh]

Can you tell that to the 60 day trial that I just downloaded 30 days ago? I had to go in and change that manually.

Re:What's the obsession with filesystems?

[Laur]

1) FAT is a very simple file system and the Linux implementation of NTFS is even less complete than ext2 is on Windows.

Really? What exactly is NTFS-3G missing? You can even use NTFS as your root or boot partition.

Re:What's the obsession with filesystems?

[slittle]

Compression, multiuser encryption (with key recovery), reparse points, proper ACLs with dynamic inheritance (as I said, POSIX ACLs are primitive and not worth using)?

Re:What's the obsession with filesystems?

[the narf]

No, it won't.

AdvFS was ported to HP-UX, but was never released on that platform.

Aha!

[Geek of Tech]

But can it run Linu... oh... right.

how soon before MS or one of their lackies....

[WindBourne]

claim this? I think that I hear SCO lawyers already knocking on the door.

Re:how soon before MS or one of their lackies....

[Anonymous Coward]

Oh wow are you ever witty, Mr. FunnyMan! But seriously, I think you're a fucking jerkoff.

Re:how soon before MS or one of their lackies....

[Anonymous Coward]

wow; coming from somebody like you, that was impressive.

Just what we needed!

[Anonymous Coward]

Another ReiserFS killer!

I'm waiting for Reiser4

[Anonymous Coward]

Why use this second rate filesystem when you can use the revolutionary Reiser4 designed by World Famous Computer Scientist Hans Reiser?

Re:A new open file system?

[east coast]

Around here it's hard to tell who's serious and who's not anymore. It's amazing some of the things that get asked around here seriously. Just look up the Ask Slashdot section and you'll see tons of it.

Take him for ballast...

[mkcmkc]

I'm always happy to see a company GPL code, but I have to say that having used both, I think ext3 is considerably more solid than AdvFS...

Ask Slashdot

[spun]

I am totally serious: why does the back of my left ear smell like cheese doodles? I don't store any kind of foodstuffs behind my ear, and I bathe regularly. Please help.

Re:Ask Slashdot

[The End Of Days]

The gnomes sneak into your bedroom while you sleep and rub the back of your ear with orange cheese powder, then sneak off. The best thing to do is not sleep until you see them.

Re:Ask Slashdot

[east coast]

Put in an Ask Slashdot. I'm sure you'll get tons of helpful advice.

Re:Ask Slashdot

[Anonymous Coward]

Whoosh

Re:Ask Slashdot

[Anonymous Coward]

Whoosh!

Re:Ask Slashdot

[Anonymous Coward]

Have you been playing "Find the Saltine"?

Re:Ask Slashdot

[fimbulvetr]

At least they're not stealing underpants anymore. Must have been because I saved that gnome in halflife 2 episode 2. Ever since then, they seem to be treating me better.

Re:Ask Slashdot

[larpon]

you've been waiting so long to find a chance to post this haven't you? ;P

Re:Ask Slashdot

[Anonymous Coward]

I am totally serious: why does the back of my left ear smell like cheese doodles? I don't store any kind of foodstuffs behind my ear, and I bathe regularly. Please help.

Regularity alone isn't enough! What is called for is FREQUENCY!

Re:Ask Slashdot

[Anonymous Coward]

More importantly, what does the back of your right ear smell like?

Re:Ask Slashdot

[spun]

Nothing. Isn't that weird?

Re:A new open file system?

[fm6]

When somebody asks a question that could be answered by a very simple Google, they're either being funny or they're so terminally lazy it's silly to respond too them. And when the question is about a guy whose murder trial has been in the news (especially the nerdcentric news) for months, I think it's safe to assume that the questioner is not being lazy.

Interesting

[99BottlesOfBeerInMyF]

Everyone has been looking at ZFS to provide a whole lot of this same feature set, but the CDDL license has been a significant stumbling block. Releasing AdvFS as GPL could actually put it in the running for real world adoption and use on a large scale. I think Sun already considered this a battle won and may now have to rethink their strategy. If they released Sun as GPL in the next month, I'd be willing to bet AdvFS would probably be largely ignored and become a historical footnote. If Sun waits and lets it gain traction (as they tend to do) it could be they will find themselves with another cool technology they sat on too long and which has been replaced y the OSS community.

Re:Interesting

[fimbulvetr]

I remember reading responses by kernel devs saying they would not put ZFS into the kernel, regardless of license. IIRC, it was because it violated in so many spectacular ways the concept of layering.

Re:Interesting

[Fweeky]

Sun already have ZFS in Solaris, Nexenta, FreeBSD, OS X, and FUSE, I don't think they're in much danger of it fading into obscurity just yet.

In other news, HAMMER is shaping up nicely, and neatly sidesteps pretty much all license concerns.

Re:Interesting

[Trixter]

I remember reading responses by kernel devs saying they would not put ZFS into the kernel, regardless of license. IIRC, it was because it violated in so many spectacular ways the concept of layering.

Yes, which is how it is able to do the amazing things that it does. Some of the stuff ZFS does -- and only ZFS does -- is because the storage management and filesystem are merged.

The people who bash ZFS haven't used it, haven't researched it, or both.

Re:Interesting

[peawee03]

I bash ZFS after using it, researching it, and trying to write a homebrew fsck utility for it after a pool decided it wasn't going to import anymore.

It's another FS in its first generation, and therefore it sucks just as bad as other young filesystems. I'll think about trying it again in a few years.

Filesystems and BIOSs are interesting

[suggsjc]

I find filesystems and BIOSs intriguing. They are kinda like voodoo, in that you don't really see or configure them (to a certain extent). They do what they do and you don't think about them. However, they can (possibly) have more impact on performance that any tweaks you can do (kernel or application).

I know that some people (read: sysadmins) definitely do think about their filesystem, but even then its usually only when you are installing a system or in the event something goes wrong.

I'll add this on my list of JusticeLeagueHardware!

[Anonymous Coward]

GameBoy Advance: ./
Advance Speaker System: ./
Advance Laxative: ./
Advance Filesystem: ./
Advance Car Insurance: O_o

Sorry but Nemesis is the sucky one...

[Anonymous Coward]

...not Insurrection. It wasn't perfect or anything, but to say it sucks just goes too far.

Ob HIMYM

[Anonymous Coward]

Don't you mean:

It'll be legen-- wait for it... ...

Tru64 goodness

[JayMcB74]

I really hope everyone will join me in thanking HP for this and encourage them to release more of the Tru64 OS, HP has been on my $&!â list since they bought and buried this years ago. They are sitting on so much good IP that I really wish that they would only make printers and just the 4000+ series at that.

Re:Tru64 goodness

[cparker15]

I'm glad I expanded my threshold before I posted the comment I was originally going to post. HP just donated a whole bunch of their code to the community, and people are so ungrateful that they're actually complaining about it. Huh??!

Thanks, HP! :)

Re:Tru64 goodness

[uassholes]

I used to be in DEC SW services. Some of their SW products were good, but the Alpha was outstanding. HP can go to hell and suck donkey ass for destroying it and other DEC products in favor of Fucktanium and their own horseshit.

Re:Tru64 goodness

[uassholes]

Forgot to mention: 1) VMS is also outstanding. A VMS cluster apparently holds the record for "uptime"; over 10 years: http://www.openvms.org/stories.php?story=06/01/08/4531954 2) Did I mention Carly Fiorina sucks ass

Re:Tru64 goodness

[MichaelSmith]

Hey don't hold back. Tell us how you really feel.

Re:Tru64 goodness

[Anonymous Coward]

Wait a minute. What's this Tru64 OS!?! Some sort of new Ubuntu variant?

Re:Tru64 goodness

[JayMcB74]

http://en.wikipedia.org/wiki/Tru64 http://www.levenez.com/unix/history.html#03 Just one of the best Operating Systems ever made for clusters

Re:Tru64 goodness

[Anonymous Coward]

Ahh the glorious 4000s, of all the printers, these are indeed my truest friend. Only for these friends will I take the time to replace a fuser, or perhaps wipe clean their imaging drum before the standard shake-try-trash problem solving.

Good times, bad times, my 4000s are always there, ready to print my every whim. I'll even forgive the one inverted (colors and orientation) testpage, that was totally my bad for using a naughty PS driver on you, faithful friend.

Re:Tru64 goodness

[Anonymous Coward]

I'd be thanking them if they had released this under a BSD license.

Small File system, native support, please.. please

[tempest69]

Ok, I understand the reasons for moving from Ext2 to ext3.. but then all this effort to support a bunch of Me-too's journaled file systems each with some marginal improvements over the rest of a crowded field. It seems like a bunch of work for a minor payoff.... The problem that I see that isnt addresses in native linux file systems is small files. try and copy a folder with 50k files each sized from 1k to 10 k each 100 meg total.. so copying a tar file with this much information is an operation that can occur in 4 seconds or less. BUT as small files it is not even close to as fast.. the copy time can run 40 minutes... the file system isnt right for this kind of work. Anyway I would like to see a much wider array of file systems out there.. especially a file system that is designed to handle small files in a manner which is near the operation bandwidth of a conventional hard drive. Now I'm aware that this isnt a concern for a bunch of people.. but it really should be.. small files are what cause really nasty bottlenecks. look at windows it loads information off the hard drive way too slow during bootup

End-of-life open sourcing

[Animats]

This is another end-of-life open sourcing. Tru64 is a legacy OS from the 1980s, but it still has some users, so HP is dumping the code out there.

Re:End-of-life open sourcing

[greg1104]

Your conclusion may be true, but the supporting details are a bit off. Check out Tru64. While the original OSF/1 code was started in the late 80's, the first release wasn't until 1992. The earliest reference anybody on Wikipedia has found to AdvFS being available dates to 1993.

STOP LAUGHING YOU HEARTLESS BASTARDS!

[Tetsujin]

That's not funny! It's wrong! It's wrong to laugh at other people's misery! Stop laughing!

I mean, look at this:
"The last file system I messed around with was absolute murder."

That is clearly meant to poke fun at how EXT3 is gradually replacing EXT2. A lot of people worked very hard on EXT2, it's served the Linux community well for a long time, so I don't think it's right to make fun of it like this!!!

Re:STOP LAUGHING YOU HEARTLESS BASTARDS!

[Anonymous Coward]

Umm, maybe you got this and are just being obtuse, but I'm pretty sure it was actually a reference to Dr. Hannibal Reiser.

Re:STOP LAUGHING YOU HEARTLESS BASTARDS!

[Tetsujin]

Umm, maybe you got this and are just being obtuse, but I'm pretty sure it was actually a reference to Dr. Hannibal Reiser.

Really? Are you sure?

I wondered why I had Fava Beans in /lost+found, you could be on to something... I see great things coming your way, your insight has served you well...

If only... What could have been w/o HP's NIH issue

[Anonymous Coward]

The irony of this is that Tru64, at the time of the HP/Compaq debacle, had (my estimate) 99% of the SVR4 compatibility layer complete and could have been vetted as HP-UX on Alpha and Itanium by recompiling the HP-UX environment on top of the Mach kernel that runs Tru64. The key is that Tru64 is itself simply a UNIX compatibility layer on top of Mach 2.5. The Itanium port was essentially complete at the time. This would have given HP-UX TruCluster and AdvFS functionality as well as providing Tru64 users a viable path forward under the HP banner rather than the wholesale defection that occurred. I find it interesting that HP is continuing to extend the lifetime of a "dead" product - now to 2012.

Re:Small File system, native support, please.. ple

[drspliff]

Well, ReiserFs handled this by tail packing, while traditionally you're limited to whole FS blocks with ReiserFS you can store multiple small files or the tails of files into a single block.

It's a little bit of a problem though because the FS is now doing more to write files, but from a performance perspective is very good for read performance (stat & file content often stored in the same block). That's very good for creating tar archives of large directory structures quickly which solves half the problem, but it's take longer to extract (I don't have the numbers for exactly how much longer).

Just as an example, ReiserFS + RAID1 is amazing in the right setting with less than ~10% writes, such as large content caches esp. with a large write-through cache. (*wonders what'll happen to the FS he loves now that Mr Reiser is in prison*)

The only way to get optimal performance for lots of small files is to be sequentially stored one after another, preceded by the directory structure and stat information in one big block that's loaded into memory. This is really for read-only data like uh.. tape drives, rom filesystems (seen cramfs?).

I guess what I'm trying to say is that filesystems have adapted to compromise between read & write ratios, and any that favors one too much is no longer general purpose or very useful to many people. There will be breakthroughs every now & then, and increasingly fast storage (flash? in-ram? holographic? quantum?) is invented and becomes cheaper, but there are only so many different ways you can reinvent the wheel.

Re:If only... What could have been w/o HP's NIH is

[turgid]

You're not a PHB are you? Let me explain it, DEC/HP/Compaq is a PHB company. When these decisions were taken, unix was legacy and Windows NT was the Way Forward. To hell with technical or business requirements. With enough spin and shiny marketing, all things are possible. That's why we're all running 32-bit Windows PCs and the entire world's servers are running an NT-derivative on itanic. Unix is dead. RISC is dead. x86 is 32-bit only.

Re:A new open file system?

[K. S. Kyosuke]

Isn't he the antagonist in Hellreiser? The daemonic killer who keeps a journal of its victims.

I currently use Tru64 in production at least..

[Bonzoli]

I currently use Tru64 in production at least for another month. One of the issues with this encapsulation type FS process is it sucks. If I had to try and figure out how to merge two File systems by some vote of talking heads, this would be the result. It has some strong and good things it does well, but the way Tru64 merged it's file systems together, makes the final product a huge pain to administer and fix. Learn what you can from the code, and make something better. Do not try and port this crap to something else as is, you wont be happy.

Why do you think HP bought again the newer Veritas File system and didn't use the already payed for version they picked up with Tru64?

It has some good things in it. Pick them out carefully and learn from them. Then think about what is needed to administer your File systems in real life, and implement it.

Re:I currently use Tru64 in production at least..

[Anonymous Coward]

I have 2 Tru64 5.1B systems in production and also a Digital Unix 4.0D system, all running Advfs. I think that you maybe dont know how to use the tools or something because the volume management and filesystem are pretty slick with Advfs.

simply create a domain(disk pool) and add file sets(volumes) and your off!

the feature set is very close to the 'nexgen' zfs. physical volume and logic volume management rolled up into 1. fast, low cost snapshots. very good journaling/transaction logging. efficient disk usage.

also, as a cluster filesystem it is comparable to GFS, but GFS is not a great general purpose filesystem. GFS is not terribly fast! advfs is quite fast in cluster environments.

some other nice things is that it can actually be shrunk while online. You can have 8 9GB drives and remove 3 members, which will consolidate the data to the remaining members, then replace those with 18GB drives, then pull the 9GB drives and replace with 18GB drives, all live. You have pull larger drives out of an array and shrink that array easily. you can add a disk to a 4 disk stipe set and the filesystem will arrange the data to a 5 disk stripe, ZFS cant even do that cleanly because the first strip set will stay intact and the next drive will get glued on the end. zpool --list will show this!

Mod parent troll...

[renegadesx]

Epic fail

Re:Mod parent troll...

[mehemiah]

not just yet. Im sure that's a valid question that can't be answered by google but maybe in an afternoon IRC chat hopping. I don't know the answer.
I get that if you Look at the GPL code while writing your own, you must put yours under the gpl as well but CDDL isn't exactly clear on what you can't do when looking at the code. if zfs was written while looking at the CDDL solaris kernel and then put under gpl, linux users couild port it, and post bug reports and patches back to sun for them to look at and fix zfs code. I dont think the GPL code can infect the code it was devrived from. I haven't really looked at the CCDL

Re:Mod parent troll...

[renegadesx]

The GPL mandates that changes to the code must be GPL'd too. So any bug fixes, performance enhancments or new features are avaliable to not just the forked project but the origional project too. The CDDL is derived from the Mozilla license which was diliberatly GPL2 incompatable however there people disagreeing on weather or not it is compatible with GPL3.

Reason I flagged parent as troll was not about the CDDL, that at least prevents code from being slipped into propietry applications. BSD license has no such restrictions and people can just copy the code and not give anything back, keep the big fixes, enchancments and improvements e.g Microsoft has quite a bit of BSD networking code in Windows, have they given any code improvments back? What about OS X? They are not required to have the Darwin kernel to be open, they just do it because the community model works

As for the Microsoft "open" licenses? Give me a break. This guy is trolling, almost twitter style

IRIX XFS was better than HP-UX file systems...

[ClarisseMcClellan]

You had to be rich to afford IRIX. It was possible to get any storage problem solved - if your clients had the money. The guys in post production houses were using IRIX to shift around a lot of full-frame multi-layer video a good fifteen years ago. At the time IRIX was what was needed, not the offerings of IBM, Sun or HP.
I guess that HP-UX has moved on since the days of the 'PA-RISC' chip but it is late to the Linux party where even SGI'd legendary XFS doesn't get much of a mention. It is yet another file system.

Re:IRIX XFS was better than HP-UX file systems...

[wkcole]

HP-UX isn't really relevant. AdvFS was a carpetbagger on HP-UX, not a native.

AdvFS comes out of the Digital side: OSF/1 aka Digital Unix aka Tru64.

It shares ancestry with Veritas Storage Foundation (aka VxVM+VxFS) roughly around Veritas 2.x, when Digital bought a license from Veritas in order to have their own tightly integrated file system and volume manager for OSF/1 on Alpha that couldn't be held hostage by the 800-lb gorillas of the time: the Sun+AT&T alliance and IBM. As such, AdvFS is very much like VxFS in structure, terminology, features, and even tool names, and shares most of its strengths.

Re:Small File system, native support, please.. ple

[Anonymous Coward]

but then all this effort to support a bunch of Me-too's journaled file systems each with some marginal improvements over the rest of a crowded field. It seems like a bunch of work for a minor payoff.. all what effort?
This is HP opening their own (or rather, their acquired) code, not Linux kernel developers spending their own time on it.

Also, AdvFS is hardly some me-too filesystem. It was one of the most advanced filesystems of its time, and significantly predates ext3 - and ZFS.

HP are not (directly) trying to solve problems with Linux filesystems, so the rest of your post is pointless.

FAT and all it's limitations still show up...

[WoTG]

Sure, it doesn't show up on servers or workstations anymore, but FAT is alive and kicking on every digital camera, most Flash drives, and many cell phones and PDA's. I'm waiting for the day when the FAT table gets screwed up on one of these devices. I know it'll happen some day... but when and where...

Re:A new open file system?

[mehemiah]

actually I think this should be rated, Offtopic because, though he did such a thing, he didn't develope this one. I think the "who?" was in refering to the fact that few use True64 and I am suprised HP still dealt with unix instead of moving upgrading their clients to linux.

There are advantages to doing stuff in the FS

[DragonHawk]

Snapshotting, striping, mirroring, resizing, encryption, etc, all of it can be done through the device mapper stack.

There are advantages to doing stuff at the filesystem layer. One of the biggest gains is that the filesystem is aware of the difference between allocated vs unallocated space. At the block layer, you can waste a lot of resources on snapshots, mirrors, encryption, etc., of unallocated space. (Copy-on-write block devices sound like a solution -- as long as you never delete anything and only do changes-in-place.) With snapshot capabilities in the filesystem, you can get more useful semantics (like the ability to easily access past versions of a given file without mounting umpteen snapshots). Similarly with encryption: People frequently only want to cipher selected files, but don't want to organize stuff between different filesystem partitions, but still want the convenience of having the cipher be transparent to the application. (Whether AdvFS in particular takes advantage of any of this, I have no idea.) I'm not saying *you* should care about any of this, but some people do.

And resizing a block device without resizing the filesystem inside it is... an interesting idea. ;-)

There are advantages to the layered approach, too, as you note. Personally, I'm of the opinion that the two approaches can co-exist in the universe without causing instability in the space-time continuum. Let the user chose what to use, based on what best suits their use. One can even use them both on the same system, or even layer the many-feature filesystems on top of LVM -- for the worst of both worlds! ;-)

Filesystem drivers require effort to implement

[DragonHawk]

Explain to me why my Linux installation has no problem dealing with FAT32 and NTFS, but my Windows installation cannot handle Ext2 very well.

You'd have to ask the people writing EXT2/3 code for Windows. Filesystem drivers do not spring into existence though spontaneous generation. They actually require someone to write them. And by all accounts, writing a filesystem driver is rather difficult. If there's little interest in having working EXT2/3 code for Windows, that's not the fault of Windows. (Well, it might be an indication that few people want to go back to Windows, and that might be due to the design of Windows, but that's a human behavior issue, not a technical one.)

Agree with first poster - about time

[Master of Transhuman]

But it doesn't go nearly far enough.

HP needs to kill HP/UX, IBM needs to kill AIX, and anybody else with a proprietary UNIX needs to kill it, and donate the source code to Linux. Including Sun with Solaris.

Had they done this ten years ago, Linux would be running the show now, instead of Microsoft.

The big companies have utterly no need for a proprietary UNIX that does nothing but jack up their development costs. Donate the existing code to Linux, wait until what fits and makes Linux sufficiently enterprise-level is adopted, then adopt Linux as their unified platform. Then they can devote development expenses to differentiating themselves with system management software, which is the sort of software open source tends to lag in producing.

By sitting on their asses, all they've done is give Microsoft an opening into the server market. Eventually the server market will be either dominated by Windows or shared equally with Linux, anyway. Nobody's going to care if the proprietary UNIXes go away as long as the necessary features from them are available in Linux.

Re:Agree with first poster - about time

[Thundersnatch]

wait until what fits and makes Linux sufficiently enterprise-level is adopted

I don't think enterprise-level customers or shareholders would appreciate that wait very much...

Is this used in the Swedish surveillance system?

[Anonymous Coward]

Since HP built the super cluster that's gonna be used to wiretap all of Sweden's internet and phones (and everyone who has any dealings with anyone in Sweden, or has any traffic that happens to pass through Sweden), one wonders if this is the FS that drives the beast? If so, it should be pretty gosh darn impressive.

Re:Small File system, native support, please.. ple

[sasami]

...with ReiserFS you can store multiple small files or the tails of files into a single block.

AdvFS was doing that about 15 years ago.

ultrix and digital unix source code

[Anonymous Coward]

You know, the ultrix source code is available via harhan's ftp sit:

ftp://ifctfvax.harhan.org/pub/UNIX/thirdparty/Ultrix-32/sources/

tinyurl 4alun4

Also the digital unix source code is on the edonkey2000 p2p network

As a former Digital UNIX software engineer!

[masinick]

I worked in the Digital UNIX engineering group from 1995 until 1998. The name Digital UNIX was already being used at the time that I joined the group, though the UNIX product in the Version 3 era was called Digital OSF/1. Digital UNIX V4.0 definitely used the UNIX name because it passed all of the branding requirements. I cannot recall if we also named V3.2 Digital UNIX or not - that was around the turning point from OSF/1 to UNIX in naming.

You are wrong about Compaq making the name Tru64 UNIX. We decided that before Compaq grabbed us. Whether we had a release out the door, perhaps not. Internally we calleed V4.0 the Platinum release. We called V5.0 the Steel release. I left after Build level 16. There were at least 20 builds in the release. Sometime near that time Compaq acquired Digital, so that is why it appears that the Tru64 name is a Compaq name, but that is not true, the Digital engineering and marketing people came up with the name.

Reminds me of a fun story. We had some cool sweatshirts made. We wanted to call it butt kicking (and a bunch of other stuff) Linux, but marketing named it instead and called it Digital UNIX. The engineers had a good sense of humor and a great deal of pride in the OS. Too bad the rest of the corporate culture stifled it. I believe in the 1995-2000 era it was the best Linux available.

Re:As a former Digital UNIX software engineer

[masinick]

You are right on with this. HP wanted to close Spit Brook Road entirely. Several of the original AdvFS and TruCluster developers were long gone - I knew quite a few of them, and I used to regularly eat lunch with one of the early AdvFS developers. This was about HP getting rid of their former Digital (called Compaq) engineers and closing facilities. They may not have saved money by dumping AdvFS and Trucluster projects by their cost, but by closing Spit Brook Road, I am sure they saved plenty.

Re:Small File system, native support, please.. ple

[tempest69]

1. reiser isnt natively supported..

2. I want selection in file systems, not just a bunch of GP choices.. I want special purpose choices for those spots where it is really needed.

3. yes, I like reiser4 and hope it goes on.

4. I kind of disagree about the concept of reading the small files as a big block only being for tape drives... I think that having a system auto-cache the small files in a directory once it's opened, having all of them read in one fell swoop is a do-able proposition.. with some limits of course.. but in most cases it's a slam dunk.

Re:As a former Digital UNIX software engineer

[the narf]

I have to agree; I work at Spit Brook Road for Dell EqualLogic, and can see the resignation written on the faces of many of the people still there on the HP side of the complex. Those who are still there will be either working from home or commuting 50 miles or more to Marlboro, Mass.

I know many of them from my times at DEC/Compaq/HP, and it's sad to watch.

On the other hand, on our side of the complex, we're doing rather well, with Dell EqualLogic arrays selling like hotcakes. And much of the development team is ex-Digital, so it's fun to be a part of building really good products inside the old ZKO complex.