Hi!

Hi!

[Eric Anopolsky]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

Hi,

I'm new here. For the past few months I've been contributing some code
and discussion to the ZFS-fuse project, but Sun's silence on the
licensing issue has left a bad taste in my mouth. I'm ready to switch
over to the light side of the force, but I have a couple of questions.

1. I've seen and modified the ZFS source code. Even if I never look at
it again, could that poison potential contributions to btrfs?

2. What needs doing? Easy stuff first, please. I've never done kernel
coding.

Cheers,
Eric


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Hi!

[Chris Mason]

On Wed, 2008-08-20 at 02:43 -0600, Eric Anopolsky wrote:
> Hi,
> 
> I'm new here. For the past few months I've been contributing some code
> and discussion to the ZFS-fuse project, but Sun's silence on the
> licensing issue has left a bad taste in my mouth. I'm ready to switch
> over to the light side of the force, but I have a couple of questions.
> 
> 1. I've seen and modified the ZFS source code. Even if I never look at
> it again, could that poison potential contributions to btrfs?
> 

For now, yes, reading and changing the ZFS source code is not a good
idea for people that want to contribute to btrfs.

> 2. What needs doing? Easy stuff first, please. I've never done kernel
> coding.

Testing, discussing and reporting bugs are a great first step.

-chris

Re: Hi!

[Miguel Sousa Filipe]

Hi,

On Wed, Aug 20, 2008 at 7:25 PM, Chris Mason <chris.mason@oracle.com> wrote:
> On Wed, 2008-08-20 at 02:43 -0600, Eric Anopolsky wrote:
>> Hi,
>>
>> I'm new here. For the past few months I've been contributing some code
>> and discussion to the ZFS-fuse project, but Sun's silence on the
>> licensing issue has left a bad taste in my mouth. I'm ready to switch
>> over to the light side of the force, but I have a couple of questions.
>>
>> 1. I've seen and modified the ZFS source code. Even if I never look at
>> it again, could that poison potential contributions to btrfs?
>>
>
> For now, yes, reading and changing the ZFS source code is not a good
> idea for people that want to contribute to btrfs.
>
>> 2. What needs doing? Easy stuff first, please. I've never done kernel
>> coding.
>
> Testing, discussing and reporting bugs are a great first step.

One thing that I would like to see, is how btrfs behaves with eavy
uses of version control systems like:
- git
- hg

big repos, greps, finds, and stuff like that.

It looks to me that git/hg/bazaar are everytime more widely used,
specially on power users' machines.
Btrfs should look good on those workloads...

Another thing that I'm particularly interested is in stuff like:
- remirror progress stats
- adding, removing,  drives, growing a volume, setting a drive faulty,
etc..  (feature parity with mdadm)
- create userland tools to enable booting from btrfs:
   - single disk and multi disk (raid1, 0 or 10)
   - which snapshot/subvolume ?
- support a migration path to ppl using mdadm + lvm.
   - provide similar tools and sintax to ppl used to lvm and mds.
(feature parity and more..)
   - provide higher level userland apps, and manage and know how to
work with LVM and MD devices,  support for equivalent (or better)
features on btrfs.
   - DeviceKit.Disks support (the future is DeviceKit! :-p) ->
       -> http://hal.freedesktop.org/docs/DeviceKit/
       -> http://lists.freedesktop.org/archives/hal/2008-May/011560.html
       -> http://gitweb.freedesktop.org/?p=DeviceKit/DeviceKit.git;a=summary
- grub support for btrfs (read only..) :D

kind regards..


-- 
Miguel Sousa Filipe

Re: Hi!

[Steve Long]

On Thursday 21 August 2008 11:47:03 Miguel Sousa Filipe wrote:
> > Testing, discussing and reporting bugs are a great first step.
>
> One thing that I would like to see, is how btrfs behaves with eavy
> uses of version control systems like:
> - git
> - hg
>
> big repos, greps, finds, and stuff like that.
>
How about kernel compiles (cf contest)? Perhaps with pull of the tree from 
cold cache or indeed several trees.

<snip good stuff>
>    - DeviceKit.Disks support (the future is DeviceKit! :-p) ->

Oh God does it have to be? Up to users what they install, but is it really the 
job of the fs to worry about a user layer on top of a lib on top of some 
other lib, one of which hasn't even got to 1.0 release, and whose author is 
apparently fine with changing everything around on distros (after all it 
hasn't got to 1.0..) but still insistent on how everyone else should be doing 
things? Not that it's anything to do with the FS, so why should we worry 
about it?

>        -> http://hal.freedesktop.org/docs/DeviceKit/

I couldn't find anything about "Disks", which may be down to my ignorance.

>        -> http://lists.freedesktop.org/archives/hal/2008-May/011560.html
>        ->
*groan* "the way forward is the model where you have a policy-less privileged 
mechanism that can be controlled by an unprivileged GUI policy agent"
Some of us quite like existing Unix permissions, especially on our 2 or 3 user 
desktops, and that kind of thing has been done, eg in mandriva, for quite a 
while now. Great if that's what people are happy with (personally I think 
scrapping dcop was a *huge* mistake) but I don't want it on my system any 
more than I _have_ to, to get apps to work (which is why I love Gentoo.)

> http://gitweb.freedesktop.org/?p=DeviceKit/DeviceKit.git;a=summary - grub
> support for btrfs (read only..) :D

Great, I see that's moving quickly, no code updates in 4 months. I'm guessing 
that's not because it's a stable and mature project that doesn't need any 
more work on it..
Tell me again what this has to do with a FS in the kernel; are btrfs supposed 
to change their code in any way to work with DeviceKit?

I agree with all the other stuff you posted, so please don't take my antipathy 
toward HAL and *Kit as criticism of you.

Regards,
steveL.

Re: Hi!

[Miguel Sousa Filipe]

On Sun, Aug 24, 2008 at 8:02 AM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> On Thursday 21 August 2008 11:47:03 Miguel Sousa Filipe wrote:
>> > Testing, discussing and reporting bugs are a great first step.
>>
>> One thing that I would like to see, is how btrfs behaves with eavy
>> uses of version control systems like:
>> - git
>> - hg
>>
>> big repos, greps, finds, and stuff like that.
>>
> How about kernel compiles (cf contest)? Perhaps with pull of the tree from
> cold cache or indeed several trees.

I believe Chris allready cover that workload in his tests.. but can't hurt. :D

>
> <snip good stuff>
>>    - DeviceKit.Disks support (the future is DeviceKit! :-p) ->
>
> Oh God does it have to be? Up to users what they install, but is it really the
> job of the fs to worry about a user layer on top of a lib on top of some
> other lib, one of which hasn't even got to 1.0 release, and whose author is
> apparently fine with changing everything around on distros (after all it
> hasn't got to 1.0..) but still insistent on how everyone else should be doing
> things? Not that it's anything to do with the FS, so why should we worry
> about it?
>
>>        -> http://hal.freedesktop.org/docs/DeviceKit/
>
> I couldn't find anything about "Disks", which may be down to my ignorance.
>
>>        -> http://lists.freedesktop.org/archives/hal/2008-May/011560.html
>>        ->
> *groan* "the way forward is the model where you have a policy-less privileged
> mechanism that can be controlled by an unprivileged GUI policy agent"
> Some of us quite like existing Unix permissions, especially on our 2 or 3 user
> desktops, and that kind of thing has been done, eg in mandriva, for quite a
> while now. Great if that's what people are happy with (personally I think
> scrapping dcop was a *huge* mistake) but I don't want it on my system any
> more than I _have_ to, to get apps to work (which is why I love Gentoo.)

even if I like the gentoo or openbsd way, that doesn't help having
good btrfs support on
all the other distros that use HAL or its descendants.

>
>> http://gitweb.freedesktop.org/?p=DeviceKit/DeviceKit.git;a=summary - grub
>> support for btrfs (read only..) :D
>
> Great, I see that's moving quickly, no code updates in 4 months. I'm guessing
> that's not because it's a stable and mature project that doesn't need any
> more work on it..
> Tell me again what this has to do with a FS in the kernel; are btrfs supposed
> to change their code in any way to work with DeviceKit?
>
> I agree with all the other stuff you posted, so please don't take my antipathy
> toward HAL and *Kit as criticism of you.

I share much of your opinions about hal and these new (leaky)
abstraction layers, but having a current/decent linux install without
all that hal stuff (with gnome or kde) is next to impossible.

My concearn is more of btrfs having equal support on those dandy
apps/layers, that will be used by fedora, ubuntu, opensuse, etc...
I want in a years time, have a "format with BTRFS" option on a regular
fedora/ubuntu install.



>
> Regards,
> steveL.
> --
> 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
>



-- 
Miguel Sousa Filipe

Testsuite

[Steve Long]

Sorry for delay in replying, was on holiday.		
Firstly: thanks for your patience; I was a bit brusque, and for that I must 
apologise.

On Monday 25 August 2008 22:56:50 Miguel Sousa Filipe wrote:
> On Sun, Aug 24, 2008 at 8:02 AM, Steve Long <slong@rathaus.eclipse.co.uk> 
wrote:
> > On Thursday 21 August 2008 11:47:03 Miguel Sousa Filipe wrote:
> >> One thing that I would like to see, is how btrfs behaves with eavy
> >> uses of version control systems like:
> >> - git
> >> - hg
> >>
> >> big repos, greps, finds, and stuff like that.
> >
> > How about kernel compiles (cf contest)? Perhaps with pull of the tree
> > from cold cache or indeed several trees.
>
> I believe Chris allready cover that workload in his tests.. but can't hurt.
> :D
>
More the merrier :-)

> > Not that it's anything to do with the FS, so why should we worry about it?
> >
> even if I like the gentoo or openbsd way, that doesn't help having
> good btrfs support on
> all the other distros that use HAL or its descendants.
>
Sure and I do have HAL running here, I simply don't include anything optional 
for it. I am still unclear as to what the FS living under the VFS has to do 
with the hal layer (and I freely admit this is from ignorance; dbus looked 
quite nice as a protocol when I looked at it fwtw.) Is there anything 
specific that a FS has to do which is not already covered by interfacing 
correctly with the kernel (and providing a useful range of ioctls)?

> > I agree with all the other stuff you posted, so please don't take my
> > antipathy toward HAL and *Kit as criticism of you.
>
> I share much of your opinions about hal and these new (leaky)
> abstraction layers, but having a current/decent linux install without
> all that hal stuff (with gnome or kde) is next to impossible.
>
Agreed.

> My concearn is more of btrfs having equal support on those dandy
> apps/layers, that will be used by fedora, ubuntu, opensuse, etc...
> I want in a years time, have a "format with BTRFS" option on a regular
> fedora/ubuntu install.
>
++ again. I don't see that being an issue if the coders are happy with what 
it's doing under the hood, although of course it needs to be tested more 
widely, and that QA process would shake out what needs work to interface 
nicely with userland (especially wrt recovery/snapshotting and so on, which 
afaict is all planned for some point.)

We can use some of the infra we use for the unofficial hardened Gentoo [1] 
(GCC 4.x) to trac and bugfix a testsuite if that would be of any use. (We'll 
be mirroring it soon.) I have fairly good bash and sh/awk skills fwtw, and 
I'm sure some other users have lots of stuff to contribute. Is that helpful 
(I'm thinking in terms of managing the workload and keeping it off core devs' 
backs since this would pretty much all be scripts) or would it simply be 
unwanted duplication?

If anyone already has a git repo with test stuff, please let us know and we'll 
gladly contribute patches etc. to that.

Regards,
SteveL.

[1] https://hardened.gentooexperimental.org/secure/

Testsuite (was: Re: Hi!)

[Steve Long]

> Testing, discussing and reporting bugs are a great first step.
>
Just wondering whether btrfs has, or might want, something like this:
http://blogs.sun.com/bill/entry/zfs_and_the_all_singing

I don't have anything like it from btrfs-progs, apart from btrfs-debug-tree.
I'm sure you're doing tests internally and users are testing stuff too; 
formalising it a bit and collaborating on that element might be useful?

(Apologies if I'm missing something obvious.)

Re: Testsuite (was: Re: Hi!)

[Chris Mason]

On Mon, 2008-08-25 at 10:06 +0100, Steve Long wrote:
> > Testing, discussing and reporting bugs are a great first step.
> >
> Just wondering whether btrfs has, or might want, something like this:
> http://blogs.sun.com/bill/entry/zfs_and_the_all_singing
> 
> I don't have anything like it from btrfs-progs, apart from btrfs-debug-tree.
> I'm sure you're doing tests internally and users are testing stuff too; 
> formalising it a bit and collaborating on that element might be useful?
> 
> (Apologies if I'm missing something obvious.)

We don't have an official test suite yet, but a few people are working
on various parts of it.  It is definitely an area where collaboration is
useful and needed.

-chris

Re: Testsuite (was: Re: Hi!)

[Christoph Hellwig]

On Mon, Aug 25, 2008 at 08:31:38AM -0400, Chris Mason wrote:
> On Mon, 2008-08-25 at 10:06 +0100, Steve Long wrote:
> > > Testing, discussing and reporting bugs are a great first step.
> > >
> > Just wondering whether btrfs has, or might want, something like this:
> > http://blogs.sun.com/bill/entry/zfs_and_the_all_singing
> > 
> > I don't have anything like it from btrfs-progs, apart from btrfs-debug-tree.
> > I'm sure you're doing tests internally and users are testing stuff too; 
> > formalising it a bit and collaborating on that element might be useful?
> > 
> > (Apologies if I'm missing something obvious.)
> 
> We don't have an official test suite yet, but a few people are working
> on various parts of it.  It is definitely an area where collaboration is
> useful and needed.

And I'd like to again say that if you want to start on a testsuite it
might be a good idea to extend the xfs testsuite.  It already deals with
udf and partially nfs and having one testsuite to run on multiple
filesystems is always a good idea.  It already supports testcases
specific to a certain filesystem or OS.