Tru64 Unix Advanced File System (AdvFS) Now GPL 226
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."
What's the point? (Score:5, Interesting)
Is there some reason to pick this file system over any of the other 100 file systems you can get for Linux?
As a former Digital UNIX admin... (Score:5, Interesting)
...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.
Good News Indeed (Score:4, Interesting)
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. /S
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.
Re:What's the point? (Score:4, Interesting)
Nah dude, SGI's xfs (in vanilla Linux since ages now) can do all of those tricks, too.
Re:As a former Digital UNIX admin... (Score:5, Interesting)
Linux Weekly News [lwn.net] 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.
Re:AdvFS (Score:3, Interesting)
Re:What's the point? (Score:3, Interesting)
Re:What's the point? (Score:4, Interesting)
Hopefully this will make Sun re-consider licensing ZFS under the GPLv2.
Re:What's the point? (Score:5, Interesting)
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? (Score:4, Interesting)
Tru64 goodness (Score:5, Interesting)
Re:Tru64 goodness (Score:2, Interesting)
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! :)
If only... What could have been w/o HP's NIH issue (Score:1, Interesting)
Re:Tru64 goodness (Score:3, Interesting)
Re:What's the point? (Score:3, Interesting)
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:
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:As a former Digital UNIX admin... (Score:3, Interesting)
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:What's the point? (Score:3, Interesting)
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? (Score:3, Interesting)
And seriously--BitKeeper worked for Linus's needs. He's a pragmatist, not an idealist.
Agree with first poster - about time (Score:3, Interesting)
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.