Btrfs devel - Jun 2008 - HP opensourced advfs from tru64 and what it means for btrfs

http://advfs.sourceforge.net/ HP open sourced the advfs filesystem
from tru64 Unix today under the gplv2.

From the page

"""
Our objective is to make the code available so that Linux developers
can pick and choose pieces
that make sense for existing and new linux file systems.  Its also a
good reference for anyone
interested in file systems.  However, we discourage Tru64 users from
trying to build and use the
code as it won''t be supported by HP on Tru64.
"""

Would it make sense to look at using any of the code from this in
btrfs, or would it be easier to
re-implement it all over again? Even though filesystems ported from
other Posix operating systems to Linux (Ever looked at XFS code)
can be ugly, this might be a way to accelerate btrfs development.
If nothing else, it might be interesting to see how HP solved problems
btrfs will soon be solving.

-- 
Jeff Schroeder

Don''t drink and derive, alcohol and analysis don''t mix.
http://www.digitalprognosis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi.

On Mon, Jun 23, 2008 at 07:37:32AM -0700, Jeff Schroeder (jeffschroed@gmail.com)
wrote:
> http://advfs.sourceforge.net/ HP open sourced the advfs filesystem
> from tru64 Unix today under the gplv2.
...
 
> Would it make sense to look at using any of the code from this in
> btrfs, or would it be easier to
> re-implement it all over again? Even though filesystems ported from
> other Posix operating systems to Linux (Ever looked at XFS code)
> can be ugly, this might be a way to accelerate btrfs development.
> If nothing else, it might be interesting to see how HP solved problems
> btrfs will soon be solving.
Sure it is interesting as studing anything new, but there is nothing in
advfs which can prevent btrfs from success. Virtually nothing.
Advfs is quite old technology built on top of almost 20 years old ideas
and hardware, while the former can still be (and likely is) valid,
hardware made significant progress. Also transaction log approach can
be very slow in lots of cases. I''m not sure using advfs code is ever
possible in btrfs: they are completely different filesystems, which
share mostly only ideas on what end user may or may not want to have.
Also having own new code is better from lots of viewpoints: from time
spent to write vs time to understand, from understandability of some
internal features and so on.
> Don''t drink and derive, alcohol and analysis don''t mix.
> http://www.digitalprognosis.com
Depending on analysis type :)

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2008-06-23 at 18:50 +0400, Evgeniy Polyakov
wrote:
> Hi.
> 
> On Mon, Jun 23, 2008 at 07:37:32AM -0700, Jeff Schroeder
(jeffschroed@gmail.com) wrote:
> > http://advfs.sourceforge.net/ HP open sourced the advfs filesystem
> > from tru64 Unix today under the gplv2.
> 
> ...
>  
> > Would it make sense to look at using any of the code from this in
> > btrfs, or would it be easier to
> > re-implement it all over again? Even though filesystems ported from
> > other Posix operating systems to Linux (Ever looked at XFS code)
> > can be ugly, this might be a way to accelerate btrfs development.
> > If nothing else, it might be interesting to see how HP solved problems
> > btrfs will soon be solving.
> 
> Sure it is interesting as studing anything new, but there is nothing in
> advfs which can prevent btrfs from success. Virtually nothing.
> Advfs is quite old technology built on top of almost 20 years old ideas
> and hardware, while the former can still be (and likely is) valid,
> hardware made significant progress.
In general, the rules that make filesystems go haven''t changed in a
long
time.   Disks are slow, ram is faster, and cpu is both infinitely fast
and important to share with other things running on the hardware.

There is a great deal we can learn from any long standing FS in terms of
layout optimizations, allocation policies and ease of use.

Is there code we can lift 100% from advfs?  It is hard to say for sure,
but being able to copy policy and basic algorithms is definitely
important.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jun 23, 2008 at 02:21:09PM -0400, Chris Mason (chris.mason@oracle.com)
wrote:
> > Sure it is interesting as studing anything new, but there is nothing
in
> > advfs which can prevent btrfs from success. Virtually nothing.
> > Advfs is quite old technology built on top of almost 20 years old
ideas
> > and hardware, while the former can still be (and likely is) valid,
> > hardware made significant progress.
> 
> In general, the rules that make filesystems go haven''t changed in
a long
> time.   Disks are slow, ram is faster, and cpu is both infinitely fast
> and important to share with other things running on the hardware.
I believe if things are that simple, you would not start btrfs? :)
> There is a great deal we can learn from any long standing FS in terms of
> layout optimizations, allocation policies and ease of use.
Sure.
> Is there code we can lift 100% from advfs?  It is hard to say for sure,
> but being able to copy policy and basic algorithms is definitely
> important.
There was similar xfs migration story, and still there is btrfs.

I completely agree that there might be some very interesting ideas
implemented, but I believe that all them we could already know about,
and porting theirs implementation into the new FS will not be easy
steps. I fully appreciate advfs became open and belive that it will get
some commnunity support, but I think that we are already behind its
milestone.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2008-06-23 at 22:45 +0400, Evgeniy Polyakov
wrote:
> On Mon, Jun 23, 2008 at 02:21:09PM -0400, Chris Mason
(chris.mason@oracle.com) wrote:
> > > Sure it is interesting as studing anything new, but there is
nothing in
> > > advfs which can prevent btrfs from success. Virtually nothing.
> > > Advfs is quite old technology built on top of almost 20 years old
ideas
> > > and hardware, while the former can still be (and likely is)
valid,
> > > hardware made significant progress.
> > 
> > In general, the rules that make filesystems go haven''t
changed in a long
> > time.   Disks are slow, ram is faster, and cpu is both infinitely fast
> > and important to share with other things running on the hardware.
> 
> I believe if things are that simple, you would not start btrfs? :)
> 
Grin, just because everyone knows the rules doesn''t mean you
shouldn''t
try playing.  SSD does change the dynamics as well in ways that I think
btrfs is best suited to handle.

The idea is that well established filesystems can teach us quite a lot
about layout, and about the optimizations that were added in response to
customer demand.  Having the code to these optimizations is very useful.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 24 Jun 2008, Evgeniy Polyakov wrote:
> Sure it is interesting as studing anything new, but there is nothing in
> advfs which can prevent btrfs from success. Virtually nothing.
As Bdale commented on the LWN article:

http://lwn.net/Articles/287108/

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

NB: Asides from briefly using AdvFS under OSF/1 back in the mid-90''s
I''ve
no other link to it or HP.

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP