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
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 -- 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 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 -- 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 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..) :DGreat, 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. -- 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
> 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.) -- 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-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 -- 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, 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. -- 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 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 -- 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
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/ -- 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