John Ogness | 3 Jul 11:55 2010
Picon

DazukoFS 3.1.3 released

Hi,

I have decided to move 3.1.3 to the latest stable release. There was
an issue reported for 3.1.2, which has not been followed:

http://lists.gnu.org/archive/html/dazuko-help/2010-01/msg00003.html

It is not known if 3.1.3 also has this issue, but I assume it
does. Feedback, comments, and patches are welcome.

John Ogness

--

-- 
Dazuko Maintainer
John Ogness | 3 Jul 12:57 2010
Picon

container support in DazukoFS

[Cc: Eric Biederman because of his container feedback on LKML.
 Hi Eric, the Dazuko-Devel mailing list is register-only, but if you
 reply to me, then I can post your comments on the list.]

Hi,

I've been wondering what we could do to make DazukoFS more acceptable
for mainline inclusion. Aside from making DazukoFS more complete:

http://lists.gnu.org/archive/html/dazuko-devel/2010-06/msg00000.html

the main issue reported from LKML reviews was that we need to support
containers. I think I have a solution for this, which will also make
DazukoFS more flexible when not using containers.

My idea is the following:

1. There is only 1 global device "/dev/dazukofs.ctrl".

2. When a group is added (using the "add" or "addtrack" commands),
DazukoFS will create the "/dev/dazukofs.N" group device within the
container-space of the process adding the group. This means that
contained environments can create their own local group devices. For
systems not using containers this is also an improvement because it
means group devices are created dynamically (instead of the 10 static
groups that exist now).

3. When a process reads the global control device to see the group
names, only the groups within the same container-space as the reading
process are shown. This keeps information about other containers
(Continue reading)

Eric W. Biederman | 3 Jul 17:42 2010

Re: container support in DazukoFS

John Ogness <dazukolist3 <at> ogness.net> writes:

> [Cc: Eric Biederman because of his container feedback on LKML.
>  Hi Eric, the Dazuko-Devel mailing list is register-only, but if you
>  reply to me, then I can post your comments on the list.]

I am not willing to discuss design ideas in detail on a closed list,
as such I have copied a couple appropriate mailing lists to have such
a discussion.

> I've been wondering what we could do to make DazukoFS more acceptable
> for mainline inclusion. Aside from making DazukoFS more complete:
>
> http://lists.gnu.org/archive/html/dazuko-devel/2010-06/msg00000.html
>
> the main issue reported from LKML reviews was that we need to support
> containers. I think I have a solution for this, which will also make
> DazukoFS more flexible when not using containers.

That is a very odd way of putting it.   We really don't allow the
ability to compile out container support.  So you really have only
two cases.  When there is only one instance of various namespaces
or when there are many.    Your code is simply broken if it doesn't
handle namespaces properly, especially the mount namespace.

> My idea is the following:
>
> 1. There is only 1 global device "/dev/dazukofs.ctrl".
>
> 2. When a group is added (using the "add" or "addtrack" commands),
(Continue reading)

Eric W. Biederman | 3 Jul 18:40 2010

Re: container support in DazukoFS

ebiederm <at> xmission.com (Eric W. Biederman) writes:

> John Ogness <dazukolist3 <at> ogness.net> writes:
>
>> [Cc: Eric Biederman because of his container feedback on LKML.
>>  Hi Eric, the Dazuko-Devel mailing list is register-only, but if you
>>  reply to me, then I can post your comments on the list.]
>
> I am not willing to discuss design ideas in detail on a closed list,
> as such I have copied a couple appropriate mailing lists to have such
> a discussion.
>
>> I've been wondering what we could do to make DazukoFS more acceptable
>> for mainline inclusion. Aside from making DazukoFS more complete:
>>
>> http://lists.gnu.org/archive/html/dazuko-devel/2010-06/msg00000.html
>>
>> the main issue reported from LKML reviews was that we need to support
>> containers. I think I have a solution for this, which will also make
>> DazukoFS more flexible when not using containers.
>
> That is a very odd way of putting it.   We really don't allow the
> ability to compile out container support.  So you really have only
> two cases.  When there is only one instance of various namespaces
> or when there are many.    Your code is simply broken if it doesn't
> handle namespaces properly, especially the mount namespace.

I just looked back at the reviews, and what I see is that your code
essentially got the a brush off, as not really being worth reviewing.
The comments were largely to point out giant design flaws in your
(Continue reading)

Serge E. Hallyn | 3 Jul 23:13 2010

Re: container support in DazukoFS

Quoting Eric W. Biederman (ebiederm <at> xmission.com):
> John Ogness <dazukolist3 <at> ogness.net> writes:
> For the mount namespace which sounds like you primarily care about the
> APIs are:
> clone( ... CLONE_NEWNS ... )
> unshare( CLONE_NEWNS )
> mount( ... )
> chroot( ... )

and pivot_root

> They have been in the kernel since at least 2.5.early.  If you are doing
> interesting things with filesystems and you don't understand those APIs
> I don't see how you can possibly create correct code.
> 
> 
> Eric
> _______________________________________________
> Containers mailing list
> Containers <at> lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

John Ogness | 4 Jul 01:15 2010
Picon

Re: container support in DazukoFS

On 2010-07-03, ebiederm <at> xmission.com (Eric W. Biederman) wrote:
>> I've been wondering what we could do to make DazukoFS more acceptable
>> for mainline inclusion.
>>
>> [...]
>
> I just looked back at the reviews, and what I see is that your code
> essentially got the a brush off, as not really being worth
> reviewing.

I didn't get that impression. Especially since posting the patches led
to a relatively positive LWN.net article from Jake Edge.

> The comments were largely to point out giant design flaws in your
> approach to you, more than a serious hey this is a good idea, here a
> couple of little problems you need to fix to make it a good
> implementation.

The only giant design flaws that were discussed were related to
stackable filesystems in general and affect current mainline code
(eCryptfs) just as much as DazukoFS. Since eCryptfs also has these
issues and was accepted mainline, I did not view this as a reason to
reject DazukoFS.

As I stated in the original patch posts, one of the reasons for adding
another stackable filesystem to mainline would be to help identify
common functionality between the stackable filesystems. And then
together figure out how we can solve these problems, which currently
affect any stackable filesystem in Linux.

(Continue reading)

Lino Sanfilippo | 8 Jul 18:29 2010

Patch 1/5


Hi all,

here are some patches against the recent stable dazukofs version (3.1.3).
Hope you find them useful.

Regards,
Lino Sanfilippo

Patch 1:
Implements the gettr() inode operation. This is for filesystems that 
implement
their own operation instead of using the generic one (like xfs).

Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
ALLGEMEINE GESCHÄFTSBEDINGUNGEN
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb
***************************************************
Attachment (dazukofs-3.1.3-patch1.diff): text/x-patch, 2050 bytes
_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
(Continue reading)

Lino Sanfilippo | 8 Jul 18:38 2010

Patch 2/5


This patch enables behaviour compatible with BSD signal semantics by 
making the read() calls
on the dazukofs devices restartable across signals.

Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
ALLGEMEINE GESCHÄFTSBEDINGUNGEN
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb
***************************************************
Attachment (dazukofs-3.1.3-patch2.diff): text/x-patch, 1849 bytes
_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Lino Sanfilippo | 8 Jul 18:40 2010

Patch 3/5


This one disables seeking on the dazukofs devices, so one has not longer to
seek around after reading/writing on a dazukofs device.

Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
ALLGEMEINE GESCHÄFTSBEDINGUNGEN
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb
***************************************************
Attachment (dazukofs-3.1.3-patch3.diff): text/x-patch, 3920 bytes
_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Lino Sanfilippo | 8 Jul 18:52 2010

Patch 4/5


This patch fixes a missing cleanup in cases where an error occurs
after an event has already been assigned to a group.
Before an event has not been put back to the "todo" list properly
(the list_del() for the working list was missing) and also was not
put back in cases of error in dazukofs_group_read().

There is still something missing:
If a filedescriptor has already been opened for an event, it has to
be closed before it is put back to the "working list".
I will send a fix for this issue with another patch.

Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
ALLGEMEINE GESCHÄFTSBEDINGUNGEN
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb
***************************************************
Attachment (dazukofs-3.1.3-patch4.diff): text/x-patch, 7264 bytes
_______________________________________________
Dazuko-devel mailing list
Dazuko-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/dazuko-devel

Gmane