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

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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.

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...

[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.

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: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.

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.

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.

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.