Infrastructure Software

thq for your kind response!

can u suggest any 3rd parties?

REGARDS

PAWAN K

You'll have to research that yourself. I haven't tried any of the ZFS implementations for Linux.

THANQ

The following link might be helpful. zfs-fuse is available from the EPEL project. More info here: http://zfs-fuse.net/

Or try the port done by the Lustre ZFS team at LLNL (http://zfsonlinux.org/lustre.html ):

http://zfsonlinux.org/

Nevertheless, I agree with Avi that BtrFS is the future on Oracle Linux ;-)

I sometimes wonder why "everyone" needs to cook their own file system soup. What is so special about btrfs or zfs, that .eg. advfs cannot do?

http://en.wikipedia.org/wiki/AdvFS

It was was the standard filesystem of Tru64 Unix (DEC/Compaq/HP) for many years and from what I can tell it has all the support, tools and features one would imagine from a modern filesystem, including file sets, file domain (LVM/LSM), clustering, snap shot of active and inactive volumes, softraid, undelete, etc. It was already introduced in 1993. One of the things I really liked about it were the option to create real mount points that report under "df" without having to partition the drive. It was rock-solid and used on high-end commercial systems and on its source code was released under GNU General Public License version 2 at SourceForge in 2008 in order to be compatible with the Linux kernel license.

Perhaps interesting readings:
The many lives of AdvFS
http://news.cnet.com/8301-13556_3-9975201-61.html

I think AdvFS did not have copy-on-write, data and metadata checksum...

And, AdvFS did not have a cool guy giving presentations and calls his company "big evil": https://www.youtube.com/watch?v=hxWuaozpe2I

I didn't call us Big Evil, I called us the Dark Side. Come over, we have cookies! :)

Hmm, save a cookie for me - I will eventually visit Australia again! :D

Comparing btrfs with a filesystem that's a decade old? For what it's worth: http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH96DTE/TITLE.HTM. It think it was ahead of anything else that existed at the time.

Perhaps some of the technologies that make up Advfs, i.e. transaction logs, are somewhat dated by now, but as far as I can tell it provides most of the fancy features shown by btrfs and zfs. And what features are really required and most useful in the end? Trying to keep it simple is often the best idea.

I really cannot say anything negative about btrfs, and certainly cannot undermine its efforts, nor can I really suggest much in favor of advfs except its long history and experience running in high-end and commercial environments.

Sometimes I just wonder why there are so many filesystems like ocfs, acfs, btrfs, zfs, reiserfs, gfs, etc.

hi

http://en.wikipedia.org/wiki/Btrfs its supporting upto RAID10,what about vraids/vdisk!will it support that too?
is it possible to have advFS in OEl?


kind regards

AdvFS only supports Tru64 & HP-UX (not a production port). Currently, no one is porting AdvFS to Linux or any other kernels. In theory it is not too hard to port a filesystem to a new kernel, but:

1) AdvFS is too old, BtrFS pretty much can do more than AdvFS and is more modern - eg. checksum, COW (which can be a bad thing for metadata intensive workloads, BTW).

2) while each kernel has a VFS layer, the APIs are not portable.

3) the virtual memory layer is somewhat integrated with the filesystem. So things like direct I/O need to be handled differently on Linux.

4) AdvFS was written 20 years ago, so I'd assume that many of the internal data structures are not multi-core friendly. AdvFS might not perform well on today's mulit-core hardware. So by the time you finish handling 1-3 and can successfully run something useful, the performance would be really bad on the 32-core processor entry-level server.


3 years ago, you need a full rack server with 128 threads to handle millions of TPC-C transactions:

http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=112011801

This year, you can buy a 5U server with 160 threads, install Oracle Linux with UEK R2 and get similar performance. The guy from the dark side said that the server and the kernel had to be released before mid of this year, so start saving up now and get two!

http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=108061001

The Tru64 UNIX kernel was multi-threaded and supported up to 64 processors. AdvFS and TruClusters used lots of kernel threads on Tru64 UNIX. The architecture was already 64-bit 20 years ago. AdvFS was certainly not written 20 years ago and then left as it was. I guess there is no question whether AdvFS should or ever will be ported to Linux, but it simply demonstrates how backward the PC/Intel industry really is. I think Tru64 was the most advanced Unix system. Too bad that HP pulled the plug. I guess it's just another example how the IT industry often prefers cheaper trivial solutions over more expensive superior solutions. Anyway, it seems btrfs it is and what it should be. I just don't understand why there have to be 10 different file systems.

I think the focus was different for Intel at that time. PC was supposed to be cheap so that everyone can buy one.

Even these days, my laptop comes with 32-bit Windows 7, and yet I don't find it limiting my computing. When I boot to Linux to do my work (Open Grid Scheduler: http://gridscheduler.sourceforge.net/ ), I run 64-bit Linux. I needed to boot to 64-bit Linux because a lot of my users are running 64-bit Linux as well.

At that time, Alpha was not much faster - yes, the clock speed was much higher, and the power draw was much higher too. I recall the SPEC marks for Alpha may be at most 2X (or 3X?) of that of the fastest x86 chips.

Eventually, one can't just keep patching & re-writing the code to handle new things. The design needs to be changed to handle new workloads and new stuff (like COW, SSD/TRIM). Even Linux has MinixFS, ext to ext4, and there's also ReiserFS with the "kills your wife" feature! As I mentioned above, filesystems are not completely portable, and thus each kernel team develops its own FS.

Alpha systems were multiuser systems often supporting several hundreds of users sessions per machine, whereas the PC was usually having trouble enough to handle just one. Comparing x86 32-bit CISC and 64-bit RISC architecture is like comparing apples and oranges. Both architectures have their pros and cons, but a server will benefit from 64-bit technology. The x86_64 CPU actually isn't really a 64-bit CPU as such. Most modern CPU's use RISC internally, but x86_64 comes with x86 CISC and only a limited amount of 64-bit registers to be able to address large memory. CISC uses more complex instructions that make it easier for programmers, but it isn't always the most efficient.
Isn't that where major and minor versions of software usually come into play?

To be honest, it does not bother me how many different file systems there are. I think a server does not need a FS that is too fancy in general - I'm not saying that btrfs was. Disk space has become relatively cheap and for larger installations the storage will most likely be external, usually with it's own type of disk management software. A file system may have to be able to adjust online, but it's also a matter of how the system layout is designed.

AdvFS, for instance, was designed to do all tasks online without the need to restart the system, but the price was complexity. Reading about something and actually using something often isn't the same. What a sysadmin does not need when trouble occurs is having a bunch of angry users at the neck and having to go through a 1000 page manual and try not to look stupid.

I think filesystem problems are one of the most annoying and devastating problems and often enough means to perform a known good restore as long as it is possible when "Danger, Will Robinson". I think reasonable simplicity and a good backup are the best prevention from disaster, regardless of how much a product or filesystem will promise.

Edited by: Dude on Feb 7, 2012 5:02 PM

Not trying to start a flame war, but it really is not me who started comparing x86 and Alpha.

Not everything needs to be 64-bit. Many applications benefit from the smaller 32-bit memory footprint.

x86-64 is as 64-bit as Alpha, Power, SPARC or MIPS.

With the Dark Side pulling the plug on the Itanium/Itanic - when we are moving to 128-bit processors in the future, I can guarantee you that there will be a 128-bit x86 processor.

And modern CISC processors use RISC as well. And, there are reasons why AMD did not want to have 32 general purpose registers - when AMD was designing the AMD64 ISA, the team simulated the chip with 16 general purpose registers, and the performance was not far worse than the other one with 32 general purpose registers. And the advantage is that you get tighter encodings in the instructions.

These days, CISC or RISC is not important at all. And no one really is coding the whole application in assembly language. Also, with pre-decoded instructions in the cache and hard-wired x86 instructions (that are as efficient as RISC instructions), most common CISC instructions behave like RISC ones anyways.

When you can just throw enough money at a problem, you can get a good implementation from a bad original design.

I mentioned that the PC/Intel industry is backward to other systems and hardware that already existed or still exist in regard to AdvFS. Unfortunately it means having to deal with it today and I just don't think having dozens of different file systems is a good plan. Alpha and 32-bit are objects you brought to the discussion.
I suggest you search the subject in Google to find out this is wrong.
I don't know where this wisdom stems, sounds like MS Windows. However, I reject this kind of corrupt philosophy.

As far as I know, a relatively bug-less 64-bit program behaves the same whether it is built on x86-64, Alpha, Power, SPARC or MIPS.

As an ex-fulltime compiler developer (now I still play with Open64), I can tell you that the compiler pretty much handles all the minor differences in each architecture.

Windows is not as bad as the 3.1 days.

It seems we are seeing it from a different perspective. I suggest to put it to rest.

Yup, and no hard feelings. :-)

No worries. I think making technology opinions a personal issue would be stupid - I worked for managers who did otherwise ;-)

I'm concluding that AdvFS, now under GPL, could still be very useful, but it is out of scope since it has not been ported to Linux.

The BtrFS filesystem looks very promising. However, unlike AdvFS, it is not a cluster file system. Apparently, Btrfs's main goal right now is to be the best non-cluster file system, according to: https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html

I think it would be cool if BtrFS was also a cluster file system, and could replace OCFS, ACFS and GFS.

IIRC, HP did not opensource the TruCluster code, and the code at sourceforge is just a non-cluster file system.

Just like XFS is opensource, but CXFS is not.
I've read "NFS Illustrated" a few years ago, and I think to build a good network filesystem or cluster filesystem, there may be some hooks needed, but you don't need to design a new disk filesystem just to support a network/cluster filesystem.

I guess I'm just not very thrilled about another file system and I'm not fully aware and familiar with all the file systems that exist. I think in the end it is neither the cheapest nor the most superior product that finds broad acceptance, but rather the one that causes the least doubt. Most people will probably prefer to stick to whatever is default for that reason, including IT professionals.

ASM and ACFS, for instance, uses some clever and unique concepts, but in order to get to the files you need a can opener. Oracle makes great software, but somewhat cumbersome admin interfaces. I think Oracle could benefit from having a standard cross platform file system. Something that combines ASM and BtrFS and OCFS, is transparent to the OS at least in order to copy and browse files, and comes with a more intuitive interface than EM/dbconsole It is not easy to pack ease of use and features, and it may sound contrary to many Unix developers, but it can be done and I believe it will be worth the effort to set a new standard. AdvFS with TruCluster, AdvFS and LSM GUI (lsmsa) are just an old example that could be inspiring.