UnionMount status?

UnionMount status?

[Michal Suchanek]

Hello

I was wondering in what state is the Linux UnionMount. As all other
union solutions were rejected from the kernel so far the development
on them is stagnating and it's not exactly easy to get them patched on
top of new kernels.

There is a repo at
http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=summary

which has tags for some older kernels up to 2.6.32-rc5 and the code
does not seem merged into current kernels such as 2.6.34-rc1, I don't
see it in config.

Thanks

Michal

Re: UnionMount status?

[J. R. Okajima]

Michal Suchanek:
> I was wondering in what state is the Linux UnionMount. As all other
> union solutions were rejected from the kernel so far the development
> on them is stagnating and it's not exactly easy to get them patched on
> top of new kernels.

As far as I know, the development on aufs (one of other union solution)
is not stagnating, and you can easily apply it against the latest -rc
kernel.
But it never means to keep Val's UnionMount from mainlining.


J. R. Okajima

Re: UnionMount status?

[Valerie Aurora]

On Fri, Mar 19, 2010 at 01:21:53AM +0100, Michal Suchanek wrote:
> Hello
> 
> I was wondering in what state is the Linux UnionMount. As all other
> union solutions were rejected from the kernel so far the development
> on them is stagnating and it's not exactly easy to get them patched on
> top of new kernels.
> 
> There is a repo at
> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=summary
> 
> which has tags for some older kernels up to 2.6.32-rc5 and the code
> does not seem merged into current kernels such as 2.6.34-rc1, I don't
> see it in config.

Where union mounts is right now is in need of more review from VFS
experts (and thanks to those who have already reviewed it).  I'm
rewriting the in-file copyup code right now, which is dependent on a
lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and
others.  Here's my description of the problem I'm currently working,
which is where I could use review the most:

http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0

Like anyone else, VFS developers prioritize what they are working on,
and unioning file systems in general tend to be low on the list.
Union mounts is my first priority but not anyone else's. :)

Thanks for your email,

-VAL

Re: UnionMount status?

[Michal Suchanek]

On 19 March 2010 07:10, J. R. Okajima <hooanon05@yahoo.co.jp> wrote:
>
> Michal Suchanek:
>> I was wondering in what state is the Linux UnionMount. As all other
>> union solutions were rejected from the kernel so far the development
>> on them is stagnating and it's not exactly easy to get them patched on
>> top of new kernels.
>
> As far as I know, the development on aufs (one of other union solution)
> is not stagnating, and you can easily apply it against the latest -rc
> kernel.
> But it never means to keep Val's UnionMount from mainlining.

You are right, the latest aufs patch applies cleanly and compiles on
top of 2.6.34-rc1.

Thanks

Michal

Re: UnionMount status?

[J. R. Okajima]

Michal Suchanek:
> You are right, the latest aufs patch applies cleanly and compiles on
> top of 2.6.34-rc1.

But it has to be one or two weeks behind from the mainline.
It is better to check the last commit in the aufs git tree.


J. R. Okajima

Re: UnionMount status?

[Michal Suchanek]

Hello

On 19 March 2010 19:03, Valerie Aurora <vaurora@redhat.com> wrote:

>
> Where union mounts is right now is in need of more review from VFS
> experts (and thanks to those who have already reviewed it).  I'm

I don't count myself among VFS experts so I'm sorry if I am restating
or missing something obvious.

> rewriting the in-file copyup code right now, which is dependent on a
> lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and
> others.  Here's my description of the problem I'm currently working,
> which is where I could use review the most:
>
> http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0
>

On Mar 16, 7:20 pm, Valerie Aurora <vaur...@redhat.com> wrote:
> This patch shows the basic data flow necessary to implement efficient
> union mount file copyup (without the actual file copyup code).  I need
> input from other VFS people on design, especially since namei.c is
> getting some much needed reorganization.  Some background:
>
> In union mounts, a file on the lower, read-only file system layer is
> copied up to the top layer when an application attempts to write to
> it.  This is in-kernel file copyup.  Some constraints make this
> difficult:
>
> 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a
> file with mode 444).  It's inefficient and a possible security hole to
> copy up a file if no write (or maybe even read) can occur anyway.

The open fails in that case anyway so I see no reason to copy
anything. Why would you copy before you open?

On the other hand, when the open succeeds there is nothing stopping
the writes from happening save things like hardware failure or lack of
disk space. It's appropriate to create an empty inode in this case.
Did you consider creating the files as sparse and handling holes by
looking into the lower layer before /dev/zero? But then you would
perhaps need a flag that differentiates them from real sparse files.

Actually the file has to be copied even when it is open for reading
because if somebody writes it later the readonly bottom handle would
never receive the top updates.


>
> 2. Near-zero added cost for operations on non-union paths in a
> CONFIG_UNION_MOUNT kernel.  One or two flag tests is okay, but
> grabbing a lock or doing a lookup operation to find out if a file
> should be copied up is too expensive.

As I see it any file can be a part of union mount in two ways:

1) You are just looking it up so you do pay the lookup costs and you
will know where it is and if that is part of a union.

2) it's already open so you have  a handle to the file and this handle
can be tagged in some way. It is probably associated with the
originating filesystem anyway so  you just need to look that way.

>
> 3. A file should be copied up if the path (mnt + dentry) of its parent
> is from a union top layer (MNT_UNION set in mnt->mnt_flags).  We can't
> tell if a file can be copied up by looking at its inode, dentry, or
> even path, we have to know what its parent path is.

Let's see what the lookup may be like:

0) No lookup: The file is open. It's always top, no issue here.

1) Perform lookup:
  - if the path goes through non-union directory structure nothing
interesting is going on
  - if the path is currently being looked up inside an union mount it
can happen that a bottom directory exists without a corresponding top
directory. In this case the top directory has to be created. Otherwise
users who have the bottom directory open would not see new files added
(and removed) in the top layer.
  - the fact that lookup is (or is not) going on inside an union mount
is a single boolean flag which may change only on mountpoint
boundaries.

During the lookup it's easy to determine if sufficient permissions
exist to open a file. Directory permissions are recorded on the top
directories or are copied from the bottom directories to the top
directories created during lookup. Additionally files which are only
in the bottom layer can have permissions in there. If the file can be
opened then the file can be copied and must be copied on open.

I guess that the union directories are a bit special in that they are
top directories but have continuation in the bottom directory. Still
this should not concern the user as they should not get the bottom
directory handle nor the top directory handle but a union directory
handle.

On Wed, Mar 17, 2010 at 07:51:31AM +0900, J. R. Okajima wrote:

> Valerie Aurora:
> > 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a
> > file with mode 444).  It's inefficient and a possible security hole to
> > copy up a file if no write (or maybe even read) can occur anyway.

> Just a question.
> How about this case?
> When the file is writable (0644 or something) but its parent directory
> is readonly (0555), do you think the file should be copied-up?

It must appear to be copied up in one way or another.
If the mode can be changed and the FS code does not have some giant
lock that allows only one open handle at a time it cannot rely on the
directory not changing just because it does not appear to have any
write permissions at the time.

Actually in a very primitive filesystem that locks the whole directory
it might hold that the directory cannot be changed while its mode says
it is readonly but it would still have to be quite non-reentrant for
that as the directory mode and contents should be quite separate.

J. R. Okajima:
> Valerie Aurora:
> > I think what people will expect is that we copy up in that case.  I
> > can think of ways this can go wrong, but perhaps that should be an
> > explicit requirement on the top-layer file system, that it can handle
> > create/unlink() in a directory without write permission.

> I am not sure such requirement is the right way.
> How about delegating open() to keventd or some other workqueue which
> will succeed to create files under a directory without write permission?
> Of course, we should handle some error cases after creating a file.

This will fail anyway when the filesystem is actually readonly. I
guess you need the equivalent of ramfs/tmpfs to store the directory
structure. Although if you plan on supporting more than two layers in
the future you may require the top layer to be writable and still
achieve reasonable flexibility.

Thanks

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

Re: UnionMount status?

[Michal Suchanek]

On 19 March 2010 22:47, Michal Suchanek <hramrach@centrum.cz> wrote:
> Hello
>
> On 19 March 2010 19:03, Valerie Aurora <vaurora@redhat.com> wrote:
>
>>
>> Where union mounts is right now is in need of more review from VFS
>> experts (and thanks to those who have already reviewed it).  I'm
>
> I don't count myself among VFS experts so I'm sorry if I am restating
> or missing something obvious.
>
>> rewriting the in-file copyup code right now, which is dependent on a
>> lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and
>> others.  Here's my description of the problem I'm currently working,
>> which is where I could use review the most:
>>
>> http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0
>>
>
> On Mar 16, 7:20 pm, Valerie Aurora <vaur...@redhat.com> wrote:
>> This patch shows the basic data flow necessary to implement efficient
>> union mount file copyup (without the actual file copyup code).  I need
>> input from other VFS people on design, especially since namei.c is
>> getting some much needed reorganization.  Some background:
>>
>> In union mounts, a file on the lower, read-only file system layer is
>> copied up to the top layer when an application attempts to write to
>> it.  This is in-kernel file copyup.  Some constraints make this
>> difficult:
>>
>> 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a
>> file with mode 444).  It's inefficient and a possible security hole to
>> copy up a file if no write (or maybe even read) can occur anyway.
>
> The open fails in that case anyway so I see no reason to copy
> anything. Why would you copy before you open?
>

Actually the lookup is probably done as namei so the file should be
copied up anyway because the result is an inode number and to
guarantee that next namei would return the same number it's far
easiest to just create the top inode and return that.

The alternative is, of course, to create numerous lookup tables in
memory and for every operation consult the tables to determine in what
state the object in question currently is.

Thanks

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

Re: UnionMount status?

[Valerie Aurora]

On Fri, Mar 19, 2010 at 10:47:15PM +0100, Michal Suchanek wrote:
> Hello
> 
> On 19 March 2010 19:03, Valerie Aurora <vaurora@redhat.com> wrote:
> 
> >
> > Where union mounts is right now is in need of more review from VFS
> > experts (and thanks to those who have already reviewed it). ??I'm
> 
> I don't count myself among VFS experts so I'm sorry if I am restating
> or missing something obvious.

Thanks for taking a look!

> > rewriting the in-file copyup code right now, which is dependent on a
> > lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and
> > others. ??Here's my description of the problem I'm currently working,
> > which is where I could use review the most:
> >
> > http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0
> >
> 
> On Mar 16, 7:20 pm, Valerie Aurora <vaur...@redhat.com> wrote:
> > This patch shows the basic data flow necessary to implement efficient
> > union mount file copyup (without the actual file copyup code).  I need
> > input from other VFS people on design, especially since namei.c is
> > getting some much needed reorganization.  Some background:
> >
> > In union mounts, a file on the lower, read-only file system layer is
> > copied up to the top layer when an application attempts to write to
> > it.  This is in-kernel file copyup.  Some constraints make this
> > difficult:
> >
> > 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a
> > file with mode 444).  It's inefficient and a possible security hole to
> > copy up a file if no write (or maybe even read) can occur anyway.
> 
> The open fails in that case anyway so I see no reason to copy
> anything. Why would you copy before you open?

Basically, it's easiest to copy up the file at pathname lookup time,
before you do all the permission checks.  This constraint really says
that you have to wait to do the copy up until you have finished any
check that might fail.

> On the other hand, when the open succeeds there is nothing stopping
> the writes from happening save things like hardware failure or lack of
> disk space. It's appropriate to create an empty inode in this case.
> Did you consider creating the files as sparse and handling holes by
> looking into the lower layer before /dev/zero? But then you would
> perhaps need a flag that differentiates them from real sparse files.

No, I haven't considered that.  Currently, the design is to copy up
the file at open() time to simplify the code.

> Actually the file has to be copied even when it is open for reading
> because if somebody writes it later the readonly bottom handle would
> never receive the top updates.

Copying up on every single open costs too much.  Copy up on
open-for-write does have this odd effect, but I consider it the moral
equivalent of a process updating a file by copying it to a temporary
file and then renaming it over the original.

> > 2. Near-zero added cost for operations on non-union paths in a
> > CONFIG_UNION_MOUNT kernel.  One or two flag tests is okay, but
> > grabbing a lock or doing a lookup operation to find out if a file
> > should be copied up is too expensive.
> 
> As I see it any file can be a part of union mount in two ways:
> 
> 1) You are just looking it up so you do pay the lookup costs and you
> will know where it is and if that is part of a union.

Yes, we just have to record and track that information after the
lookup.  This will require a new flag or structure or structure
member.  user_path_at() is an example where we need to retain this
information but throw it away and just return the path.

> 2) it's already open so you have  a handle to the file and this handle
> can be tagged in some way. It is probably associated with the
> originating filesystem anyway so  you just need to look that way.

In general, by the time you have an open file and you want to alter
it, you've already copied it up.  But I found two exceptions to this
rule: fchown() and fchmod() are legal on an fd opened O_RDONLY.  So
we'll have to close, copyup, and re-open the file in that case.

> > 3. A file should be copied up if the path (mnt + dentry) of its parent
> > is from a union top layer (MNT_UNION set in mnt->mnt_flags).  We can't
> > tell if a file can be copied up by looking at its inode, dentry, or
> > even path, we have to know what its parent path is.
> 
> Let's see what the lookup may be like:
> 
> 0) No lookup: The file is open. It's always top, no issue here.
> 
> 1) Perform lookup:
>   - if the path goes through non-union directory structure nothing
> interesting is going on
>   - if the path is currently being looked up inside an union mount it
> can happen that a bottom directory exists without a corresponding top
> directory. In this case the top directory has to be created. Otherwise
> users who have the bottom directory open would not see new files added
> (and removed) in the top layer.

The current implementation always copies up directories on lookup.

>   - the fact that lookup is (or is not) going on inside an union mount
> is a single boolean flag which may change only on mountpoint
> boundaries.
> 
> During the lookup it's easy to determine if sufficient permissions
> exist to open a file. Directory permissions are recorded on the top
> directories or are copied from the bottom directories to the top
> directories created during lookup. Additionally files which are only
> in the bottom layer can have permissions in there. If the file can be
> opened then the file can be copied and must be copied on open.
> 
> I guess that the union directories are a bit special in that they are
> top directories but have continuation in the bottom directory. Still
> this should not concern the user as they should not get the bottom
> directory handle nor the top directory handle but a union directory
> handle.
> 
> On Wed, Mar 17, 2010 at 07:51:31AM +0900, J. R. Okajima wrote:
> 
> > Valerie Aurora:
> > > 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a
> > > file with mode 444).  It's inefficient and a possible security hole to
> > > copy up a file if no write (or maybe even read) can occur anyway.
> 
> > Just a question.
> > How about this case?
> > When the file is writable (0644 or something) but its parent directory
> > is readonly (0555), do you think the file should be copied-up?
> 
> It must appear to be copied up in one way or another.
> If the mode can be changed and the FS code does not have some giant
> lock that allows only one open handle at a time it cannot rely on the
> directory not changing just because it does not appear to have any
> write permissions at the time.
> 
> Actually in a very primitive filesystem that locks the whole directory
> it might hold that the directory cannot be changed while its mode says
> it is readonly but it would still have to be quite non-reentrant for
> that as the directory mode and contents should be quite separate.
> 
> J. R. Okajima:
> > Valerie Aurora:
> > > I think what people will expect is that we copy up in that case.  I
> > > can think of ways this can go wrong, but perhaps that should be an
> > > explicit requirement on the top-layer file system, that it can handle
> > > create/unlink() in a directory without write permission.
> 
> > I am not sure such requirement is the right way.
> > How about delegating open() to keventd or some other workqueue which
> > will succeed to create files under a directory without write permission?
> > Of course, we should handle some error cases after creating a file.
> 
> This will fail anyway when the filesystem is actually readonly. I
> guess you need the equivalent of ramfs/tmpfs to store the directory
> structure. Although if you plan on supporting more than two layers in
> the future you may require the top layer to be writable and still
> achieve reasonable flexibility.

The current implementation stores the directory structure in the
topmost directory itself using fallthrus as placeholders for lower
level directory entries.  Several people have written in-memory
solutions, look for Miklos Szeredi, Bharata Rao, and Jan Blunck's
patches.

Thanks,

-VAL

Re: UnionMount status?

[Michal Suchanek]

On 24 March 2010 00:02, Valerie Aurora <vaurora@redhat.com> wrote:
> On Fri, Mar 19, 2010 at 10:47:15PM +0100, Michal Suchanek wrote:
>> Hello
>>
>> On 19 March 2010 19:03, Valerie Aurora <vaurora@redhat.com> wrote:
>>
>> >
>> > Where union mounts is right now is in need of more review from VFS
>> > experts (and thanks to those who have already reviewed it). ??I'm
>>
>> I don't count myself among VFS experts so I'm sorry if I am restating
>> or missing something obvious.
>
> Thanks for taking a look!

Thanks for taking the time to reply.

Apparently I have missed a few properties of the current state of
union mount, especially the fact that directories are only ever stored
in the top layer and the bottom directories are only accessed once
when the merged directory is created in the top layer.

It greatly simplifies lookup operations and avoids some problems with
getting stuck in the bottom layer when something else is already
visible on the top layer.

>
>> > rewriting the in-file copyup code right now, which is dependent on a
>> > lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and
>> > others. ??Here's my description of the problem I'm currently working,
>> > which is where I could use review the most:
>> >
>> > http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0
>> >
>>
>> On Mar 16, 7:20 pm, Valerie Aurora <vaur...@redhat.com> wrote:
>> > This patch shows the basic data flow necessary to implement efficient
>> > union mount file copyup (without the actual file copyup code).  I need
>> > input from other VFS people on design, especially since namei.c is
>> > getting some much needed reorganization.  Some background:
>> >
>> > In union mounts, a file on the lower, read-only file system layer is
>> > copied up to the top layer when an application attempts to write to
>> > it.  This is in-kernel file copyup.  Some constraints make this
>> > difficult:
>> >
>> > 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a
>> > file with mode 444).  It's inefficient and a possible security hole to
>> > copy up a file if no write (or maybe even read) can occur anyway.
>>
>> The open fails in that case anyway so I see no reason to copy
>> anything. Why would you copy before you open?
>
> Basically, it's easiest to copy up the file at pathname lookup time,
> before you do all the permission checks.  This constraint really says
> that you have to wait to do the copy up until you have finished any
> check that might fail.

Yes, returning file from the bottom layer at all complicates things.
However, once you allow for that the case when the bottom file is
returned and later writing to the file is required has to be handled,
apparently. So it would be possible to return the readonly file and
make it readwrite if and when open for writing succeeds.

>
>> On the other hand, when the open succeeds there is nothing stopping
>> the writes from happening save things like hardware failure or lack of
>> disk space. It's appropriate to create an empty inode in this case.
>> Did you consider creating the files as sparse and handling holes by
>> looking into the lower layer before /dev/zero? But then you would
>> perhaps need a flag that differentiates them from real sparse files.
>
> No, I haven't considered that.  Currently, the design is to copy up
> the file at open() time to simplify the code.

A sparse file would make the open() and especially lookup code much
simpler at the cost of adding features elsewhere. Still it splits the
complexity into multiple parts which should be easier to manage and
test separately.

Also it greatly optimizes the case when the top filesystem is tmpfs
and the unchanged blocks do not have to be saved at all as well as the
case when the modified file is removed later.

Still the full copy-up should probably happen on unmount time for
disk-based top filesystem because I do not see any way how the sparse
file could be bound to the bottom filesystem so that the union can be
reliably reconstructed later. It could be made into a special sparse
file that binds to any underlying bottom file but I am not sure this
is desirable. Also the sparse file would have to specify the inode to
which it binds because otherwise renames could be quite expensive.

>
>> Actually the file has to be copied even when it is open for reading
>> because if somebody writes it later the readonly bottom handle would
>> never receive the top updates.
>
> Copying up on every single open costs too much.  Copy up on
> open-for-write does have this odd effect, but I consider it the moral
> equivalent of a process updating a file by copying it to a temporary
> file and then renaming it over the original.

Which did never really happen in this case so it might possibly break
something that tries to synchronize on files.

I am  not sure if there is any file based locking/synchronization
which is supposed to work on plain filesystem but not in this case.

Perhaps some application which has a pre-created file and then mmaps
it into multiple processes (some readonly) would run into this issue.

Thanks

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

Re: UnionMount status?

[Michal Suchanek]

On 19 March 2010 20:03, Valerie Aurora <vaurora@redhat.com> wrote:
> On Fri, Mar 19, 2010 at 01:21:53AM +0100, Michal Suchanek wrote:
>> Hello
>>
>> I was wondering in what state is the Linux UnionMount. As all other
>> union solutions were rejected from the kernel so far the development
>> on them is stagnating and it's not exactly easy to get them patched on
>> top of new kernels.
>>
>> There is a repo at
>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=summary
>>
>> which has tags for some older kernels up to 2.6.32-rc5 and the code
>> does not seem merged into current kernels such as 2.6.34-rc1, I don't
>> see it in config.
>
> Where union mounts is right now is in need of more review from VFS
> experts (and thanks to those who have already reviewed it).  I'm
> rewriting the in-file copyup code right now, which is dependent on a
> lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and
> others.  Here's my description of the problem I'm currently working,
> which is where I could use review the most:
>
> http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0
>
> Like anyone else, VFS developers prioritize what they are working on,
> and unioning file systems in general tend to be low on the list.
> Union mounts is my first priority but not anyone else's. :)
>
> Thanks for your email,
>
> -VAL
>
>

Hello

How is the unionmount going along?

I see multiple branches based off 2.6.34 kernel in the git repo.

Reading the doc I find a few points quite unsetting:

 99 What happens when I...
100
101 - creat() /newfile -> creates on topmost layer
102 - unlink() /oldfile -> creates a whiteout on topmost layer
103 - Edit /existingfile -> copies up to top layer at open(O_WR) time
104 - truncate /existingfile -> copies up to topmost layer + N bytes
if specified
105 - touch()/chmod()/chown()/etc. -> copies up to topmost layer

I'm not sure if touching a file is common operation for non-zero
files. Somebody might want working atimes in the shared root use case
so there should be an optimization in place for this case.

106 - mkdir() /newdir -> creates on topmost layer

Does this mean that the mkdir() can succeed if there is no directory
in topmost layer and there is one in the bottom layer?

That's certainly not what mkdir should do.

Thanks

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

Re: UnionMount status?

[Michal Suchanek]

Hello

FWIW I tried to apply the unionmount patch from submounts branch to my
kernel (2.6.34 Debian kernel) and boot a live system using the kernel.

The system boots but locks up during init.

The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
crashes because at the point when iscsid is started during boot as the
iscsi drive is disconnected for some reason.

As the kernel does not include aufs I cannot easily test that it works
as expected with that but both boot methods used to work with 2.6.32
kernels and aufs.

Thanks

Michal

Re: UnionMount status?

[Valerie Aurora]

On Wed, Jul 14, 2010 at 03:12:28PM +0200, Michal Suchanek wrote:
> Hello
> 
> FWIW I tried to apply the unionmount patch from submounts branch to my
> kernel (2.6.34 Debian kernel) and boot a live system using the kernel.
> 
> The system boots but locks up during init.
> 
> The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
> tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
> BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
> the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
> crashes because at the point when iscsid is started during boot as the
> iscsi drive is disconnected for some reason.

Thanks for the bug report!  I will get to work on that as soon as
possible.

> As the kernel does not include aufs I cannot easily test that it works
> as expected with that but both boot methods used to work with 2.6.32
> kernels and aufs.

I think it's quite likely the problem is with union mounts, so don't
go to the effort to test aufs just for this case.

-VAL

Re: UnionMount status?

[Michal Suchanek]

On 14 July 2010 21:30, Valerie Aurora <vaurora@redhat.com> wrote:
> On Wed, Jul 14, 2010 at 03:12:28PM +0200, Michal Suchanek wrote:
>> Hello
>>
>> FWIW I tried to apply the unionmount patch from submounts branch to my
>> kernel (2.6.34 Debian kernel) and boot a live system using the kernel.
>>
>> The system boots but locks up during init.
>>
>> The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
>> tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
>> BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
>> the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
>> crashes because at the point when iscsid is started during boot as the
>> iscsi drive is disconnected for some reason.
>
> Thanks for the bug report!  I will get to work on that as soon as
> possible.
>
>> As the kernel does not include aufs I cannot easily test that it works
>> as expected with that but both boot methods used to work with 2.6.32
>> kernels and aufs.
>
> I think it's quite likely the problem is with union mounts, so don't
> go to the effort to test aufs just for this case.
>

If you want the live CD or more details about the issue I guess I can send them.

Also the CD build system is automated so it's quite easy to try new patches.

Thanks

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

Re: UnionMount status?

[Valerie Aurora]

On Mon, Jul 19, 2010 at 06:06:36PM +0200, Michal Suchanek wrote:
> On 14 July 2010 21:30, Valerie Aurora <vaurora@redhat.com> wrote:
> > On Wed, Jul 14, 2010 at 03:12:28PM +0200, Michal Suchanek wrote:
> >> Hello
> >>
> >> FWIW I tried to apply the unionmount patch from submounts branch to my
> >> kernel (2.6.34 Debian kernel) and boot a live system using the kernel.
> >>
> >> The system boots but locks up during init.
> >>
> >> The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
> >> tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
> >> BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
> >> the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
> >> crashes because at the point when iscsid is started during boot as the
> >> iscsi drive is disconnected for some reason.
> >
> > Thanks for the bug report! ??I will get to work on that as soon as
> > possible.
> >
> >> As the kernel does not include aufs I cannot easily test that it works
> >> as expected with that but both boot methods used to work with 2.6.32
> >> kernels and aufs.
> >
> > I think it's quite likely the problem is with union mounts, so don't
> > go to the effort to test aufs just for this case.
> >
> 
> If you want the live CD or more details about the issue I guess I can send them.
> 
> Also the CD build system is automated so it's quite easy to try new patches.

Can you try the d_ino_lookup branch in the union mounts git tree?  I
fixed one bug that may be related.  Thanks,

-VAL

Re: UnionMount status?

[Valerie Aurora]

On Wed, Aug 11, 2010 at 12:08:38PM +0200, Michal Suchanek wrote:
> On 10 August 2010 18:52, Valerie Aurora <vaurora@redhat.com> wrote:
> > On Mon, Jul 19, 2010 at 06:06:36PM +0200, Michal Suchanek wrote:
> >> On 14 July 2010 21:30, Valerie Aurora <vaurora@redhat.com> wrote:
> >> > On Wed, Jul 14, 2010 at 03:12:28PM +0200, Michal Suchanek wrote:
> >> >> Hello
> >> >>
> >> >> FWIW I tried to apply the unionmount patch from submounts branch to my
> >> >> kernel (2.6.34 Debian kernel) and boot a live system using the kernel.
> >> >>
> >> >> The system boots but locks up during init.
> >> >>
> >> >> The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
> >> >> tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
> >> >> BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
> >> >> the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
> >> >> crashes because at the point when iscsid is started during boot as the
> >> >> iscsi drive is disconnected for some reason.
> >> >
> >> > Thanks for the bug report! ??I will get to work on that as soon as
> >> > possible.
> >> >
> >> >> As the kernel does not include aufs I cannot easily test that it works
> >> >> as expected with that but both boot methods used to work with 2.6.32
> >> >> kernels and aufs.
> >> >
> >> > I think it's quite likely the problem is with union mounts, so don't
> >> > go to the effort to test aufs just for this case.
> >> >
> >>
> >> If you want the live CD or more details about the issue I guess I can send them.
> >>
> >> Also the CD build system is automated so it's quite easy to try new patches.
> >
> > Can you try the d_ino_lookup branch in the union mounts git tree? ??I
> > fixed one bug that may be related. ??Thanks,
> >
> > -VAL
> >
> 
> It does not build for me.
> 
> Thanks
> 
> Michal
> 
>   CC      fs/namei.o
>   CC      security/keys/gc.o
>   CC      ipc/util.o
> fs/namei.c: In function ???__lookup_union???:
> fs/namei.c:820: error: ???struct dentry??? has no member named ???d_union_dir???
> fs/namei.c:831: error: ???struct dentry??? has no member named ???d_union_dir???
> fs/namei.c:831: error: dereferencing pointer to incomplete type
> fs/namei.c:832: error: dereferencing pointer to incomplete type
> fs/namei.c:834: error: dereferencing pointer to incomplete type
> fs/namei.c:878: warning: assignment makes integer from pointer without a cast
> fs/namei.c:886: warning: assignment makes integer from pointer without a cast
> fs/namei.c:890: error: dereferencing pointer to incomplete type
> fs/namei.c:816: warning: unused variable ???parent???
> fs/namei.c: In function ???open_union_copyup???:
> fs/namei.c:1921: warning: assignment makes integer from pointer without a cast
> fs/namei.c:1923: warning: assignment makes integer from pointer without a cast
> fs/namei.c: In function ???sys_linkat???:
> fs/namei.c:2998: warning: assignment makes integer from pointer without a cast
> fs/namei.c: In function ???sys_renameat???:
> fs/namei.c:3267: warning: assignment makes integer from pointer without a cast
> make[3]: *** [fs/namei.o] Error 1
> make[2]: *** [fs] Error 2
> make[2]: *** Waiting for unfinished jobs....

Thanks for attaching your .config.  CONFIG_UNION_MOUNT wasn't set:

# CONFIG_UNION_MOUNT is not set

Try rebuilding with that on.  Yes, it should build without
CONFIG_UNION_MOUNT and I'll test that for next release.

-VAL

Re: UnionMount status?

[Michal Suchanek]

On 16 August 2010 20:52, Valerie Aurora <vaurora@redhat.com> wrote:
> On Wed, Aug 11, 2010 at 12:08:38PM +0200, Michal Suchanek wrote:
>> On 10 August 2010 18:52, Valerie Aurora <vaurora@redhat.com> wrote:
>> > On Mon, Jul 19, 2010 at 06:06:36PM +0200, Michal Suchanek wrote:
>> >> On 14 July 2010 21:30, Valerie Aurora <vaurora@redhat.com> wrote:
>> >> > On Wed, Jul 14, 2010 at 03:12:28PM +0200, Michal Suchanek wrote:
>> >> >> Hello
>> >> >>
>> >> >> FWIW I tried to apply the unionmount patch from submounts branch to my
>> >> >> kernel (2.6.34 Debian kernel) and boot a live system using the kernel.
>> >> >>
>> >> >> The system boots but locks up during init.
>> >> >>
>> >> >> The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
>> >> >> tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
>> >> >> BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
>> >> >> the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
>> >> >> crashes because at the point when iscsid is started during boot as the
>> >> >> iscsi drive is disconnected for some reason.
>> >> >
>> >> > Thanks for the bug report! ??I will get to work on that as soon as
>> >> > possible.
>> >> >
>> >> >> As the kernel does not include aufs I cannot easily test that it works
>> >> >> as expected with that but both boot methods used to work with 2.6.32
>> >> >> kernels and aufs.
>> >> >
>> >> > I think it's quite likely the problem is with union mounts, so don't
>> >> > go to the effort to test aufs just for this case.
>> >> >
>> >>
>> >> If you want the live CD or more details about the issue I guess I can send them.
>> >>
>> >> Also the CD build system is automated so it's quite easy to try new patches.
>> >
>> > Can you try the d_ino_lookup branch in the union mounts git tree? ??I
>> > fixed one bug that may be related. ??Thanks,
>> >
>> > -VAL
>> >
>>
>> It does not build for me.
>>
>> Thanks
>>
>> Michal
>>
...
>
> Thanks for attaching your .config.  CONFIG_UNION_MOUNT wasn't set:
>
> # CONFIG_UNION_MOUNT is not set
>
> Try rebuilding with that on.  Yes, it should build without
> CONFIG_UNION_MOUNT and I'll test that for next release.
>
> -VAL
>

Sorry, I thought I enabled it.

Anyway, I changed that option in the config but it still does not build.

Thanks

Michal

  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  OBJCOPY arch/x86/boot/vmlinux.bin
  HOSTCC  arch/x86/boot/tools/build
  BUILD   arch/x86/boot/bzImage
Root device is (8, 3)
Setup is 14108 bytes (padded to 14336 bytes).
System is 2446 kB
CRC 6af7dba4
Kernel: arch/x86/boot/bzImage is ready  (#5)
  Building modules, stage 2.
  MODPOST 1351 modules
WARNING: drivers/ata/ahci_platform.o(.data+0x0): Section mismatch in
reference from the variable ahci_driver to the function
.init.text:ahci_probe()
The variable ahci_driver references
the function __init ahci_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

WARNING: drivers/net/ksz884x.o(.data+0x30): Section mismatch in
reference from the variable pci_device_driver to the function
.init.text:pcidev_init()
The variable pci_device_driver references
the function __init pcidev_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

WARNING: drivers/scsi/mpt2sas/mpt2sas.o(.text+0xb140): Section
mismatch in reference from the function _scsih_pci_error_detected() to
the function .devexit.text:_scsih_remove()
The function _scsih_pci_error_detected() references a function in an
exit section.
Often the function _scsih_remove() has valid usage outside the exit section
and the fix is to remove the __devexit annotation of _scsih_remove.

WARNING: net/l2tp/l2tp_eth.o(.exit.text+0x7): Section mismatch in
reference from the function cleanup_module() to the variable
.init.data:l2tp_eth_net_ops
The function __exit cleanup_module() references
a variable __initdata l2tp_eth_net_ops.
This is often seen when error handling in the exit function
uses functionality in the init path.
The fix is often to remove the __initdata annotation of
l2tp_eth_net_ops so it may be used outside an init section.

ERROR: "generic_readdir_fallthru" [fs/ext2/ext2.ko] undefined!
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: UnionMount status?

[Michal Suchanek]

On 17 August 2010 14:03, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 16 August 2010 20:52, Valerie Aurora <vaurora@redhat.com> wrote:
>> On Wed, Aug 11, 2010 at 12:08:38PM +0200, Michal Suchanek wrote:
>>> On 10 August 2010 18:52, Valerie Aurora <vaurora@redhat.com> wrote:
>>> > On Mon, Jul 19, 2010 at 06:06:36PM +0200, Michal Suchanek wrote:
>>> >> On 14 July 2010 21:30, Valerie Aurora <vaurora@redhat.com> wrote:
>>> >> > On Wed, Jul 14, 2010 at 03:12:28PM +0200, Michal Suchanek wrote:
>>> >> >> Hello
>>> >> >>
>>> >> >> FWIW I tried to apply the unionmount patch from submounts branch to my
>>> >> >> kernel (2.6.34 Debian kernel) and boot a live system using the kernel.
>>> >> >>
>>> >> >> The system boots but locks up during init.
>>> >> >>
>>> >> >> The first boot method uses tmpfs union/squashfs/loop/FUSE(httpfs) or
>>> >> >> tmpfs union/squashfs/loop/iso9660/loop/FUSE(httpfs) and triggers the
>>> >> >> BUG_ON(*next_ud != NULL); in union_add_dir when udev starts whereas
>>> >> >> the other method which uses tmpfs union/squashfs/loop/iso966/iscsi
>>> >> >> crashes because at the point when iscsid is started during boot as the
>>> >> >> iscsi drive is disconnected for some reason.
>>> >> >
>>> >> > Thanks for the bug report! ??I will get to work on that as soon as
>>> >> > possible.
>>> >> >
>>> >> >> As the kernel does not include aufs I cannot easily test that it works
>>> >> >> as expected with that but both boot methods used to work with 2.6.32
>>> >> >> kernels and aufs.
>>> >> >
>>> >> > I think it's quite likely the problem is with union mounts, so don't
>>> >> > go to the effort to test aufs just for this case.
>>> >> >
>>> >>
>>> >> If you want the live CD or more details about the issue I guess I can send them.
>>> >>
>>> >> Also the CD build system is automated so it's quite easy to try new patches.
>>> >
>>> > Can you try the d_ino_lookup branch in the union mounts git tree? ??I
>>> > fixed one bug that may be related. ??Thanks,
>>> >
>>> > -VAL
>>> >
>>>
>>> It does not build for me.
>>>
>>> Thanks
>>>
>>> Michal
>>>
> ...
>>
>> Thanks for attaching your .config.  CONFIG_UNION_MOUNT wasn't set:
>>
>> # CONFIG_UNION_MOUNT is not set
>>
>> Try rebuilding with that on.  Yes, it should build without
>> CONFIG_UNION_MOUNT and I'll test that for next release.
>>
>> -VAL
>>
>
> Sorry, I thought I enabled it.
>
> Anyway, I changed that option in the config but it still does not build.
>

OK, a build without the ext2 filesystem works.

Now when I try to mount the filesystem I get:

                     (initramfs) mount_full -t tmpfs -o union tmpfs /root
                      [   43.403419] tmpfs: No value for mount option
'union'
                      mount: wrong fs type, bad option, bad superblock
on tmpfs,
                             missing codepage or helper program, or other error
                             (for several filesystems (e.g. nfs, cifs) you might
                             need a /sbin/mount.<type> helper program)
                             In some cases useful info is found in syslog - try
                             dmesg | tail  or so

I wonder if the docs are out of date. They suggest to only add -o union.

I think it used to work, I recycled the scripts that produced the
halfway-booting system last time.

Thanks

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

Re: UnionMount status?

[Valerie Aurora]

On Tue, Aug 17, 2010 at 04:31:48PM +0200, Michal Suchanek wrote:
> On 17 August 2010 14:03, Michal Suchanek <hramrach@centrum.cz> wrote:
> > On 16 August 2010 20:52, Valerie Aurora <vaurora@redhat.com> wrote:
> >>
> >> Thanks for attaching your .config. ??CONFIG_UNION_MOUNT wasn't set:
> >>
> >> # CONFIG_UNION_MOUNT is not set
> >>
> >> Try rebuilding with that on. ??Yes, it should build without
> >> CONFIG_UNION_MOUNT and I'll test that for next release.
> >>
> >> -VAL
> >>
> >
> > Sorry, I thought I enabled it.
> >
> > Anyway, I changed that option in the config but it still does not build.
> >
> 
> OK, a build without the ext2 filesystem works.
> 
> Now when I try to mount the filesystem I get:
> 
>                      (initramfs) mount_full -t tmpfs -o union tmpfs /root
>                       [   43.403419] tmpfs: No value for mount option
> 'union'
>                       mount: wrong fs type, bad option, bad superblock
> on tmpfs,
>                              missing codepage or helper program, or other error
>                              (for several filesystems (e.g. nfs, cifs) you might
>                              need a /sbin/mount.<type> helper program)
>                              In some cases useful info is found in syslog - try
>                              dmesg | tail  or so
> 
> I wonder if the docs are out of date. They suggest to only add -o union.
> 
> I think it used to work, I recycled the scripts that produced the
> halfway-booting system last time.

Hm, does mount_full call the new mount binary built from the union
mounts util-linux-ng git tree?  You can find the git tree here:

http://valerieaurora.org/union/

-VAL

Re: UnionMount status?

[Michal Suchanek]

On 17 August 2010 21:51, Valerie Aurora <vaurora@redhat.com> wrote:
> On Tue, Aug 17, 2010 at 04:31:48PM +0200, Michal Suchanek wrote:
>> On 17 August 2010 14:03, Michal Suchanek <hramrach@centrum.cz> wrote:
>> > On 16 August 2010 20:52, Valerie Aurora <vaurora@redhat.com> wrote:
>> >>
>> >> Thanks for attaching your .config. ??CONFIG_UNION_MOUNT wasn't set:
>> >>
>> >> # CONFIG_UNION_MOUNT is not set
>> >>
>> >> Try rebuilding with that on. ??Yes, it should build without
>> >> CONFIG_UNION_MOUNT and I'll test that for next release.
>> >>
>> >> -VAL
>> >>
>> >
>> > Sorry, I thought I enabled it.
>> >
>> > Anyway, I changed that option in the config but it still does not build.
>> >
>>
>> OK, a build without the ext2 filesystem works.
>>
>> Now when I try to mount the filesystem I get:
>>
>>                      (initramfs) mount_full -t tmpfs -o union tmpfs /root
>>                       [   43.403419] tmpfs: No value for mount option
>> 'union'
>>                       mount: wrong fs type, bad option, bad superblock
>> on tmpfs,
>>                              missing codepage or helper program, or other error
>>                              (for several filesystems (e.g. nfs, cifs) you might
>>                              need a /sbin/mount.<type> helper program)
>>                              In some cases useful info is found in syslog - try
>>                              dmesg | tail  or so
>>
>> I wonder if the docs are out of date. They suggest to only add -o union.
>>
>> I think it used to work, I recycled the scripts that produced the
>> halfway-booting system last time.
>
> Hm, does mount_full call the new mount binary built from the union
> mounts util-linux-ng git tree?  You can find the git tree here:
>
> http://valerieaurora.org/union/
>
Yes, that's the problem. I installed a wrong package and the mount
command did not get updated.

I copy it as moutn_full into initramfs because mount is normally
something from klibc or busybox.

A dmesg can be found here:  http://paste.debian.net/84100

The system often boots but some features fail at random probably
depending on the part of init which is affected by the unionmount
failures.

Thanks

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

Re: UnionMount status?

[Valerie Aurora]

On Wed, Aug 18, 2010 at 01:30:38PM +0200, Michal Suchanek wrote:
> On 17 August 2010 21:51, Valerie Aurora <vaurora@redhat.com> wrote:
> > On Tue, Aug 17, 2010 at 04:31:48PM +0200, Michal Suchanek wrote:
> >> On 17 August 2010 14:03, Michal Suchanek <hramrach@centrum.cz> wrote:
> >> > On 16 August 2010 20:52, Valerie Aurora <vaurora@redhat.com> wrote:
> >> >>
> >> >> Thanks for attaching your .config. ??CONFIG_UNION_MOUNT wasn't set:
> >> >>
> >> >> # CONFIG_UNION_MOUNT is not set
> >> >>
> >> >> Try rebuilding with that on. ??Yes, it should build without
> >> >> CONFIG_UNION_MOUNT and I'll test that for next release.
> >> >>
> >> >> -VAL
> >> >>
> >> >
> >> > Sorry, I thought I enabled it.
> >> >
> >> > Anyway, I changed that option in the config but it still does not build.
> >> >
> >>
> >> OK, a build without the ext2 filesystem works.
> >>
> >> Now when I try to mount the filesystem I get:
> >>
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??(initramfs) mount_full -t tmpfs -o union tmpfs /root
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? [ ?? 43.403419] tmpfs: No value for mount option
> >> 'union'
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? mount: wrong fs type, bad option, bad superblock
> >> on tmpfs,
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??missing codepage or helper program, or other error
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??(for several filesystems (e.g. nfs, cifs) you might
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??need a /sbin/mount.<type> helper program)
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??In some cases useful info is found in syslog - try
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??dmesg | tail ??or so
> >>
> >> I wonder if the docs are out of date. They suggest to only add -o union.
> >>
> >> I think it used to work, I recycled the scripts that produced the
> >> halfway-booting system last time.
> >
> > Hm, does mount_full call the new mount binary built from the union
> > mounts util-linux-ng git tree? ??You can find the git tree here:
> >
> > http://valerieaurora.org/union/
> >
> Yes, that's the problem. I installed a wrong package and the mount
> command did not get updated.
> 
> I copy it as moutn_full into initramfs because mount is normally
> something from klibc or busybox.
> 
> A dmesg can be found here:  http://paste.debian.net/84100
> 
> The system often boots but some features fail at random probably
> depending on the part of init which is affected by the unionmount
> failures.

Thanks a ton!  Al just told me to rewrite that part of the code
completely.  The good news is the new version will have fewer
pointers to be unexpectedly NULL. :)

-VAL

Re: UnionMount status?

[Michal Suchanek]

On 18 August 2010 21:06, Valerie Aurora <vaurora@redhat.com> wrote:
> On Wed, Aug 18, 2010 at 01:30:38PM +0200, Michal Suchanek wrote:
>> On 17 August 2010 21:51, Valerie Aurora <vaurora@redhat.com> wrote:
>> > On Tue, Aug 17, 2010 at 04:31:48PM +0200, Michal Suchanek wrote:
>> >> On 17 August 2010 14:03, Michal Suchanek <hramrach@centrum.cz> wrote:
>> >> > On 16 August 2010 20:52, Valerie Aurora <vaurora@redhat.com> wrote:
>> >> >>
>> >> >> Thanks for attaching your .config. ??CONFIG_UNION_MOUNT wasn't set:
>> >> >>
>> >> >> # CONFIG_UNION_MOUNT is not set
>> >> >>
>> >> >> Try rebuilding with that on. ??Yes, it should build without
>> >> >> CONFIG_UNION_MOUNT and I'll test that for next release.
>> >> >>
>> >> >> -VAL
>> >> >>
>> >> >
>> >> > Sorry, I thought I enabled it.
>> >> >
>> >> > Anyway, I changed that option in the config but it still does not build.
>> >> >
>> >>
>> >> OK, a build without the ext2 filesystem works.
>> >>
>> >> Now when I try to mount the filesystem I get:
>> >>
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??(initramfs) mount_full -t tmpfs -o union tmpfs /root
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? [ ?? 43.403419] tmpfs: No value for mount option
>> >> 'union'
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? mount: wrong fs type, bad option, bad superblock
>> >> on tmpfs,
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??missing codepage or helper program, or other error
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??(for several filesystems (e.g. nfs, cifs) you might
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??need a /sbin/mount.<type> helper program)
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??In some cases useful info is found in syslog - try
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??dmesg | tail ??or so
>> >>
>> >> I wonder if the docs are out of date. They suggest to only add -o union.
>> >>
>> >> I think it used to work, I recycled the scripts that produced the
>> >> halfway-booting system last time.
>> >
>> > Hm, does mount_full call the new mount binary built from the union
>> > mounts util-linux-ng git tree? ??You can find the git tree here:
>> >
>> > http://valerieaurora.org/union/
>> >
>> Yes, that's the problem. I installed a wrong package and the mount
>> command did not get updated.
>>
>> I copy it as moutn_full into initramfs because mount is normally
>> something from klibc or busybox.
>>
>> A dmesg can be found here:  http://paste.debian.net/84100
>>
>> The system often boots but some features fail at random probably
>> depending on the part of init which is affected by the unionmount
>> failures.
>
> Thanks a ton!  Al just told me to rewrite that part of the code
> completely.  The good news is the new version will have fewer
> pointers to be unexpectedly NULL. :)
>

Actually, if I read the code correctly the pointer is unexpectedly
non-null as it is supposed to be allocated in the function in
question.

Thanks

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

Re: Unionmount status?

[Michal Suchanek]

On 16 April 2011 00:18, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
>> Apparently tmpfs does not support generic xattr.  I understand why
>> tmpfs is an attractive choice for an upper filesystem, so this should
>> be addressed.
>>
>> I see two options here:
>>
>> 1) implement generic xattr in tmpfs
>
> There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:
>
> From: Eric Paris <eparis@redhat.com>
> Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
> Date: March 29, 2011 12:56:49 PM MDT
>
> Cheers, Andreas

Applying this patch is not sufficient. Apparently more xattrs are
needed but adding them on top of this patch should be easy.

The ones mentioned in the overlayfs doc are

trusted.overlay.whiteout
trusted.overlay.opaque

The patch implements security.*

Thanks

Michal

Re: Unionmount status?

[Michal Suchanek]

On 16 April 2011 00:18, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
>> Apparently tmpfs does not support generic xattr.  I understand why
>> tmpfs is an attractive choice for an upper filesystem, so this should
>> be addressed.
>>
>> I see two options here:
>>
>> 1) implement generic xattr in tmpfs
>
> There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:
>
> From: Eric Paris <eparis@redhat.com>
> Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
> Date: March 29, 2011 12:56:49 PM MDT
>
> Cheers, Andreas

Applying this patch is not sufficient. Apparently more xattrs are
needed but adding them on top of this patch should be easy.

The ones mentioned in the overlayfs doc are

trusted.overlay.whiteout
trusted.overlay.opaque

The patch implements security.*

Thanks

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

Re: Unionmount status?

[Michal Suchanek]

On 16 April 2011 00:18, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
>> Apparently tmpfs does not support generic xattr.  I understand why
>> tmpfs is an attractive choice for an upper filesystem, so this should
>> be addressed.
>>
>> I see two options here:
>>
>> 1) implement generic xattr in tmpfs
>
> There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:
>
> From: Eric Paris <eparis@redhat.com>
> Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
> Date: March 29, 2011 12:56:49 PM MDT
>
> Cheers, Andreas

Applying this patch is not sufficient. Apparently more xattrs are
needed but adding them on top of this patch should be easy.

The ones mentioned in the overlayfs doc are

trusted.overlay.whiteout
trusted.overlay.opaque

The patch implements security.*

Thanks

Michal

Re: Unionmount status?

[Michal Suchanek]

On 16 April 2011 00:18, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
>> Apparently tmpfs does not support generic xattr.  I understand why
>> tmpfs is an attractive choice for an upper filesystem, so this should
>> be addressed.
>>
>> I see two options here:
>>
>> 1) implement generic xattr in tmpfs
>
> There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:
>
> From: Eric Paris <eparis@redhat.com>
> Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
> Date: March 29, 2011 12:56:49 PM MDT
>
> Cheers, Andreas

Applying this patch is not sufficient. Apparently more xattrs are
needed but adding them on top of this patch should be easy.

The ones mentioned in the overlayfs doc are

trusted.overlay.whiteout
trusted.overlay.opaque

The patch implements security.*

Thanks

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

Re: Unionmount status?

[Michal Suchanek]

On 16 April 2011 00:18, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
>> Apparently tmpfs does not support generic xattr.  I understand why
>> tmpfs is an attractive choice for an upper filesystem, so this should
>> be addressed.
>>
>> I see two options here:
>>
>> 1) implement generic xattr in tmpfs
>
> There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:
>
> From: Eric Paris <eparis@redhat.com>
> Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
> Date: March 29, 2011 12:56:49 PM MDT
>
> Cheers, Andreas

Applying this patch is not sufficient. Apparently more xattrs are
needed but adding them on top of this patch should be easy.

The ones mentioned in the overlayfs doc are

trusted.overlay.whiteout
trusted.overlay.opaque

The patch implements security.*

Thanks

Michal

Re: Unionmount status?

[Michal Suchanek]

On 16 April 2011 00:18, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
>> Apparently tmpfs does not support generic xattr.  I understand why
>> tmpfs is an attractive choice for an upper filesystem, so this should
>> be addressed.
>>
>> I see two options here:
>>
>> 1) implement generic xattr in tmpfs
>
> There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:
>
> From: Eric Paris <eparis@redhat.com>
> Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
> Date: March 29, 2011 12:56:49 PM MDT
>
> Cheers, Andreas

Applying this patch is not sufficient. Apparently more xattrs are
needed but adding them on top of this patch should be easy.

The ones mentioned in the overlayfs doc are

trusted.overlay.whiteout
trusted.overlay.opaque

The patch implements security.*

Thanks

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

Re: Unionmount status?

[Andreas Dilger]

On 2011-04-15, at 6:29 AM, Miklos Szeredi wrote:
> Apparently tmpfs does not support generic xattr.  I understand why
> tmpfs is an attractive choice for an upper filesystem, so this should
> be addressed.
> 
> I see two options here:
> 
> 1) implement generic xattr in tmpfs

There was a patch posted recently to add xattr support to tmpfs, so that it can use security labels:

From: Eric Paris <eparis@redhat.com>
Subject: [PATCH] tmpfs: implement xattr support for the entire security namespace
Date: March 29, 2011 12:56:49 PM MDT

Cheers, Andreas

Re: Unionmount status?

[Hugh Dickins]

On Fri, Apr 15, 2011 at 5:29 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Fri, Apr 15, 2011 at 1:51 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 15 April 2011 13:31, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Fri, Apr 15, 2011 at 1:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>
>>>> Cleaning up temporary files...
>>>> [    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
>>>> find: cannot delete `./motd': Operation not supported
>>>
>>> What is the upper filesystem type?  Is xattr support enabled?
>>>
>>
>> The upper filesystem is tmpfs and there is not option regarding XATTR
>> in the config.
>
> Apparently tmpfs does not support generic xattr.  I understand why
> tmpfs is an attractive choice for an upper filesystem, so this should
> be addressed.
>
> I see two options here:
>
> 1) implement generic xattr in tmpfs
> 2) take whiteout/opaque support from union mounts and use that
>
> Both have advantages and disadvantages.
>
> Any thoughts?

Please get together with Eric: he's having trouble whipping up
enthusiasm for his tmpfs xattr patch, he and I would both appreciate
your support (and if I've persuaded him to leave out a part of it that
you would need, join forces to call me an idiot).  Mainly I'm hoping
to hear from hch and jmorris on it, being xattr-illiterate myself.

https://lkml.org/lkml/2011/3/29/302

Hugh

Re: Unionmount status?

[Ric Wheeler]

On 04/14/2011 10:54 AM, Michal Suchanek wrote:
> On 14 April 2011 15:21, Ric Wheeler<ricwheeler@gmail.com>  wrote:
>> On 04/14/2011 05:40 AM, Miklos Szeredi wrote:
>>> On Thu, Apr 14, 2011 at 11:32 AM, Michal Suchanek<hramrach@centrum.cz>
>>>   wrote:
>>>> I guess overlayfs includes the better part of unionmount and achieves
>>>> similar level of functionality in much smaller code size and is
>>>> actively developed.
>>>>
>>>> This might make it the best candidate for inclusion so far.
>>>>
>>>> It does not (yet?) support NFS which is one of the options commonly
>>>> used with union solutions, though.
>>> NFS is supported as a lower (read-only) layer, but not as an upper
>>> (read-write) layer.
>>>
>>> Thanks,
>>> Miklos
>> I am not that concerned with the state of Val's repo, her intention was to
>> hand off the project cleanly to others and have them drive the code (that
>> hand off was the posting of the patch set). Several people (Ian, David
>> Howells and Al Viro) had been involved with union mounts recently, so we do
>> have reasonable candidates for a hand off.
>>
>> One of the concerns with unionfs is the duplication of data. Union mounts
>> avoids this with that implementation. That might make unionfs more of a
>> burden for very large file systems, but probably not a concern for many use
>> cases.
> Just to make things clear, what is a very large filesystem?
>
> A heavily compressed DVD image?
>
> Tens or hundreds  of gigabytes? Terabytes?
>
> Hundreds, thousands or hundreds of thousands of inodes?
>
> Or is testing required to determine at what size the performance
> becomes unacceptable?
>
> Thanks
>
> Michal

Very large in the number of inodes more so than fs size...

Ric

Re: Unionmount status?

[Miklos Szeredi]

On Fri, Apr 15, 2011 at 2:34 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 15 April 2011 14:29, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> 2) take whiteout/opaque support from union mounts and use that
>
> How far from importing full unionmount is that?

Whiteout/opaque support is quite separate from the rest of union
mounts, and could be reusable for overlayfs.

There are several reasons why I didn't want to go that way with:

- lots of filesystems would have to be updated
- it introduces incompatibility in the filesystem format, which can be
a real pain (not for tmpfs, obviously, since tmpfs doesn't have a
persistent backing)

There *are* advantages to doing whiteouts in the filesystem, for
example it makes file removal atomic.  But atomicity is something that
needs to be addressed in lots of other places (e.g. copy up) not just
during whiteout, and there are other ways to do that than push the
responsibility into each and every filesystem.

Thanks,
Miklos

Re: Unionmount status?

[Michal Suchanek]

On 15 April 2011 14:29, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Fri, Apr 15, 2011 at 1:51 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 15 April 2011 13:31, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Fri, Apr 15, 2011 at 1:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>
>>>> Cleaning up temporary files...
>>>> [    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
>>>> find: cannot delete `./motd': Operation not supported
>>>
>>> What is the upper filesystem type?  Is xattr support enabled?
>>>
>>
>> The upper filesystem is tmpfs and there is not option regarding XATTR
>> in the config.
>
> Apparently tmpfs does not support generic xattr.  I understand why
> tmpfs is an attractive choice for an upper filesystem, so this should
> be addressed.
>
> I see two options here:
>
> 1) implement generic xattr in tmpfs

IMHO this is a general feature that keeps overlayfs in itself clean
and small and can benefit other uses of tmpfs.

> 2) take whiteout/opaque support from union mounts and use that

How far from importing full unionmount is that?

Thanks

Michal

Re: Unionmount status?

[Michal Suchanek]

On 15 April 2011 14:29, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Fri, Apr 15, 2011 at 1:51 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 15 April 2011 13:31, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Fri, Apr 15, 2011 at 1:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>>
>>>> Cleaning up temporary files...
>>>> [    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
>>>> find: cannot delete `./motd': Operation not supported
>>>
>>> What is the upper filesystem type?  Is xattr support enabled?
>>>
>>
>> The upper filesystem is tmpfs and there is not option regarding XATTR
>> in the config.
>
> Apparently tmpfs does not support generic xattr.  I understand why
> tmpfs is an attractive choice for an upper filesystem, so this should
> be addressed.
>
> I see two options here:
>
> 1) implement generic xattr in tmpfs

IMHO this is a general feature that keeps overlayfs in itself clean
and small and can benefit other uses of tmpfs.

> 2) take whiteout/opaque support from union mounts and use that

How far from importing full unionmount is that?

Thanks

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

Re: Unionmount status?

[Miklos Szeredi]

On Fri, Apr 15, 2011 at 1:51 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 15 April 2011 13:31, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Fri, Apr 15, 2011 at 1:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>
>>> Cleaning up temporary files...
>>> [    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
>>> find: cannot delete `./motd': Operation not supported
>>
>> What is the upper filesystem type?  Is xattr support enabled?
>>
>
> The upper filesystem is tmpfs and there is not option regarding XATTR
> in the config.

Apparently tmpfs does not support generic xattr.  I understand why
tmpfs is an attractive choice for an upper filesystem, so this should
be addressed.

I see two options here:

1) implement generic xattr in tmpfs
2) take whiteout/opaque support from union mounts and use that

Both have advantages and disadvantages.

Any thoughts?

Thanks,
Miklos

Re: Unionmount status?

[Michal Suchanek]

On 15 April 2011 13:31, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Fri, Apr 15, 2011 at 1:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 14 April 2011 10:38, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Wed, Apr 13, 2011 at 5:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>>> On 13 April 2011 16:18, Jiri Kosina <jkosina@suse.cz> wrote:
>>>>> https://lkml.org/lkml/2011/3/22/222
>>>>>
>>>>
>>>> Thanks for pointing out this announcement.
>>>>
>>>> However, neither this announcement nor the document
>>>> Documentation/filesystems/overlayfs.txt included in the git tree
>>>> details how to mount the filesystem. Without that it is kind of
>>>> useless.
>>>
>>> Oh, I'll fix that in the docs.  Thanks for pointing it out.
>>>
>>> Here's how to mount:
>>>
>>>  mount -t overlayfs overlayfs -olowerdir=/lower -oupperdir=/upper /overlay
>>>
>>
>> OK, I built a small live CD with the v7 patch and I can boot it but I
>> get errors like
>>
>> Cleaning up temporary files...
>> [    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
>> find: cannot delete `./motd': Operation not supported
>
> What is the upper filesystem type?  Is xattr support enabled?
>

The upper filesystem is tmpfs and there is not option regarding XATTR
in the config.

Thanks

Michal

Re: Unionmount status?

[Miklos Szeredi]

On Fri, Apr 15, 2011 at 1:22 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 14 April 2011 10:38, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Wed, Apr 13, 2011 at 5:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>>> On 13 April 2011 16:18, Jiri Kosina <jkosina@suse.cz> wrote:
>>>> https://lkml.org/lkml/2011/3/22/222
>>>>
>>>
>>> Thanks for pointing out this announcement.
>>>
>>> However, neither this announcement nor the document
>>> Documentation/filesystems/overlayfs.txt included in the git tree
>>> details how to mount the filesystem. Without that it is kind of
>>> useless.
>>
>> Oh, I'll fix that in the docs.  Thanks for pointing it out.
>>
>> Here's how to mount:
>>
>>  mount -t overlayfs overlayfs -olowerdir=/lower -oupperdir=/upper /overlay
>>
>
> OK, I built a small live CD with the v7 patch and I can boot it but I
> get errors like
>
> Cleaning up temporary files...
> [    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
> find: cannot delete `./motd': Operation not supported

What is the upper filesystem type?  Is xattr support enabled?

Thanks,
Miklos

Re: Unionmount status?

[Michal Suchanek]

On 14 April 2011 10:38, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Wed, Apr 13, 2011 at 5:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 13 April 2011 16:18, Jiri Kosina <jkosina@suse.cz> wrote:
>>> https://lkml.org/lkml/2011/3/22/222
>>>
>>
>> Thanks for pointing out this announcement.
>>
>> However, neither this announcement nor the document
>> Documentation/filesystems/overlayfs.txt included in the git tree
>> details how to mount the filesystem. Without that it is kind of
>> useless.
>
> Oh, I'll fix that in the docs.  Thanks for pointing it out.
>
> Here's how to mount:
>
>  mount -t overlayfs overlayfs -olowerdir=/lower -oupperdir=/upper /overlay
>

OK, I built a small live CD with the v7 patch and I can boot it but I
get errors like

Cleaning up temporary files...
[    nn.nnnnnn] overlayfs: ERROR - failed to whiteout 'motd'
find: cannot delete `./motd': Operation not supported

Thanks

Michal

Re: Unionmount status?

[David Howells]

Ian Kent <ikent@redhat.com> wrote:

> I believe David was working to update the patches and his silence
> indicates he is probably bogged down with other priority work. If that's
> the case, and your still interested, I might be able to help updating
> the series some time soon. I haven't reviewed any of Val's series posts
> for a while now so I'd need to catch up with the current state of the
> project first.
> 
> I guess the first thing is to find out if David has made any progress,
> David?

I started trying to forwardport them.  It's not trivial because of Nick's RCU
pathwalk patches.

However, I noticed that the collection of patches I was working on wasn't the
most recent in Val's GIT tree, so I stopped work on them whilst I found out
from Val which was the correct branch to use.  Her reply came just before I
jetted out to LSF, and I haven't got round to working on them again.

David

Re: Unionmount status?

[Michal Suchanek]

On 14 April 2011 15:21, Ric Wheeler <ricwheeler@gmail.com> wrote:
> On 04/14/2011 05:40 AM, Miklos Szeredi wrote:
>>
>> On Thu, Apr 14, 2011 at 11:32 AM, Michal Suchanek<hramrach@centrum.cz>
>>  wrote:
>>>
>>> I guess overlayfs includes the better part of unionmount and achieves
>>> similar level of functionality in much smaller code size and is
>>> actively developed.
>>>
>>> This might make it the best candidate for inclusion so far.
>>>
>>> It does not (yet?) support NFS which is one of the options commonly
>>> used with union solutions, though.
>>
>> NFS is supported as a lower (read-only) layer, but not as an upper
>> (read-write) layer.
>>
>> Thanks,
>> Miklos
>
> I am not that concerned with the state of Val's repo, her intention was to
> hand off the project cleanly to others and have them drive the code (that
> hand off was the posting of the patch set). Several people (Ian, David
> Howells and Al Viro) had been involved with union mounts recently, so we do
> have reasonable candidates for a hand off.
>
> One of the concerns with unionfs is the duplication of data. Union mounts
> avoids this with that implementation. That might make unionfs more of a
> burden for very large file systems, but probably not a concern for many use
> cases.

Just to make things clear, what is a very large filesystem?

A heavily compressed DVD image?

Tens or hundreds  of gigabytes? Terabytes?

Hundreds, thousands or hundreds of thousands of inodes?

Or is testing required to determine at what size the performance
becomes unacceptable?

Thanks

Michal

Re: Unionmount status?

[Ric Wheeler]

On 04/14/2011 05:40 AM, Miklos Szeredi wrote:
> On Thu, Apr 14, 2011 at 11:32 AM, Michal Suchanek<hramrach@centrum.cz>  wrote:
>> I guess overlayfs includes the better part of unionmount and achieves
>> similar level of functionality in much smaller code size and is
>> actively developed.
>>
>> This might make it the best candidate for inclusion so far.
>>
>> It does not (yet?) support NFS which is one of the options commonly
>> used with union solutions, though.
> NFS is supported as a lower (read-only) layer, but not as an upper
> (read-write) layer.
>
> Thanks,
> Miklos
I am not that concerned with the state of Val's repo, her intention was to hand 
off the project cleanly to others and have them drive the code (that hand off 
was the posting of the patch set). Several people (Ian, David Howells and Al 
Viro) had been involved with union mounts recently, so we do have reasonable 
candidates for a hand off.

One of the concerns with unionfs is the duplication of data. Union mounts avoids 
this with that implementation. That might make unionfs more of a burden for very 
large file systems, but probably not a concern for many use cases.

The union mount patch set is certainly considerably larger.

Christoph had expressed some concerns about locking that I think it would be 
good to discuss again as well.

Ric

Re: Unionmount status?

[Miklos Szeredi]

On Thu, Apr 14, 2011 at 11:48 AM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> did you stop working on OverlayFS (no hear no read since 3 weeks :-))?
> You made some post-v7-patchset patches, but did not publish a v8.
>
> Also, Linus requested a finer-grained split of the big overlayfs.c
> file like in the other FS.
> What's the status on this?

I'm working on that.  Will post patches shortly.

Thanks,
Miklos

Re: Unionmount status?

[Sedat Dilek]

On Thu, Apr 14, 2011 at 10:38 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Wed, Apr 13, 2011 at 5:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 13 April 2011 16:18, Jiri Kosina <jkosina@suse.cz> wrote:
>>> https://lkml.org/lkml/2011/3/22/222
>>>
>>
>> Thanks for pointing out this announcement.
>>
>> However, neither this announcement nor the document
>> Documentation/filesystems/overlayfs.txt included in the git tree
>> details how to mount the filesystem. Without that it is kind of
>> useless.
>
> Oh, I'll fix that in the docs.  Thanks for pointing it out.
>
> Here's how to mount:
>
>  mount -t overlayfs overlayfs -olowerdir=/lower -oupperdir=/upper /overlay
>
> Thanks,
> Miklos
>

Hi Miklos,

did you stop working on OverlayFS (no hear no read since 3 weeks :-))?
You made some post-v7-patchset patches, but did not publish a v8.

Also, Linus requested a finer-grained split of the big overlayfs.c
file like in the other FS.
What's the status on this?

Regards,
- Sedat -

Re: Unionmount status?

[Miklos Szeredi]

On Thu, Apr 14, 2011 at 11:32 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> I guess overlayfs includes the better part of unionmount and achieves
> similar level of functionality in much smaller code size and is
> actively developed.
>
> This might make it the best candidate for inclusion so far.
>
> It does not (yet?) support NFS which is one of the options commonly
> used with union solutions, though.

NFS is supported as a lower (read-only) layer, but not as an upper
(read-write) layer.

Thanks,
Miklos

Re: Unionmount status?

[Michal Suchanek]

On 14 April 2011 06:50, Ian Kent <ikent@redhat.com> wrote:
> On Wed, 2011-04-13 at 21:47 +0200, Michal Suchanek wrote:
>> On 13 April 2011 21:11, Ric Wheeler <ricwheeler@gmail.com> wrote:
>> > On 04/13/2011 02:58 PM, Michal Suchanek wrote:
>> >>
>> >> On 13 April 2011 19:26, Ric Wheeler<ricwheeler@gmail.com>  wrote:
>> >>>
>> >>> On 04/12/2011 05:36 PM, Michal Suchanek wrote:
>> >>>>
>> >>>> On 12 April 2011 22:31, Ric Wheeler<ricwheeler@gmail.com>    wrote:
>> >>>>>
>> >>>>> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
>> >>>>>>
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> as some already know the Unionmount VFS union which has been in
>> >>>>>> development for some years now is the only True Union (TM) that can be
>> >>>>>> accepted into the kernel mainline by the VFS maintainers (for reasons
>> >>>>>> of their own which you can surely find if you search the web or ask
>> >>>>>> them directly).
>> >>>>>>
>> >>>>>> The current UnionMount version that can be found here:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>> >>>>>>
>> >>>>>> works for me as good as aufs does. That is I can build a live CD using
>> >>>>>> this unioning solution and it boots and runs without any apparent
>> >>>>>> issues.
>> >>>>>>
>> >>>>>> There are probably many possible uses of the union which I did not
>> >>>>>> test nor did I test long term stability of using the unioned
>> >>>>>> filesystem. As far as ephemeral live systems go it works fine for me,
>> >>>>>> though.
>> >>>>>>
>> >>>>>> The issue is that while the code is (nearly) finished it is not yet
>> >>>>>> merged into mainline and as I am not familiar with the details of
>> >>>>>> ever-changing Linux VFS layer forward-porting this code to current
>> >>>>>> kernels is somewhat challenging.
>> >>>>>>
>> >>>>>> What is the plan with unionmount now?
>> >>>>>>
>> >>>>>> What is required  for it to be merged into mainline?
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>> Michal
>> >>>>>
>> >>>>> Hi Michal,
>> >>>>>
>> >>>>> People are actively looking to see what union mount (or overlayfs)
>> >>>>> solution
>> >>>>> to pursue. Val has shifted her focus away from kernel hacking these
>> >>>>> days,
>> >>>>> but did refresh her patch set in the last month or so.
>> >>>>
>> >>>> I am not aware of such refreshed patch set, at least it is not
>> >>>> published in her repo.
>> >>>>
>> >>> Val posted the refreshed patches with the title on March 22nd:
>> >>>
>> >>> http://lwn.net/Articles/435019/
>> >>>
>> >> That article references the same four months old repo which I
>> >> mentioned at the start of the thread, only a slightly different
>> >> branch.
>> >>
>> >> While it maybe useful for testing unionmount (which I already tried)
>> >> it is not a patch against current kernel which could be used to build
>> >> current live images.
>> >>
>> >> Thanks
>> >>
>> >> Michal
>> >
>> > She did post the patch series that same date in March - you can probably
>> > grab the series from linux-fsdevel, look for this series:
>> >
>> > "[PATCH 00/74] Union mounts version something or other"
>> >
>> > Al Viro was planning on looking at her refreshed patches (he had reviewed
>> > them with her in person), but that is not going to happen any time soon so
>> > getting more eyes and testing would be great!
>> >
>>
>> Even gmame can't collect the patches back from the ML, I don't want to try.
>>
>> However, the discussion suggests that these are exactly the 4 months
>> old branch ending in a commit with the summary "Temporary commit"
>> which did not inspire confidence in me so I used the previous (also 4
>> moths old) branch.
>
> Yes, that's the impression I have too.
>
> I believe David was working to update the patches and his silence
> indicates he is probably bogged down with other priority work. If that's
> the case, and your still interested, I might be able to help updating
> the series some time soon. I haven't reviewed any of Val's series posts
> for a while now so I'd need to catch up with the current state of the
> project first.

I guess overlayfs includes the better part of unionmount and achieves
similar level of functionality in much smaller code size and is
actively developed.

This might make it the best candidate for inclusion so far.

It does not (yet?) support NFS which is one of the options commonly
used with union solutions, though.

I personally don;t use NFS and have not tested overlayfs so far so I can't tell.

Thanks

Michal

Re: Unionmount status?

[Miklos Szeredi]

On Wed, Apr 13, 2011 at 5:13 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 13 April 2011 16:18, Jiri Kosina <jkosina@suse.cz> wrote:
>> https://lkml.org/lkml/2011/3/22/222
>>
>
> Thanks for pointing out this announcement.
>
> However, neither this announcement nor the document
> Documentation/filesystems/overlayfs.txt included in the git tree
> details how to mount the filesystem. Without that it is kind of
> useless.

Oh, I'll fix that in the docs.  Thanks for pointing it out.

Here's how to mount:

  mount -t overlayfs overlayfs -olowerdir=/lower -oupperdir=/upper /overlay

Thanks,
Miklos

Re: Unionmount status?

[Ian Kent]

On Wed, 2011-04-13 at 21:47 +0200, Michal Suchanek wrote:
> On 13 April 2011 21:11, Ric Wheeler <ricwheeler@gmail.com> wrote:
> > On 04/13/2011 02:58 PM, Michal Suchanek wrote:
> >>
> >> On 13 April 2011 19:26, Ric Wheeler<ricwheeler@gmail.com>  wrote:
> >>>
> >>> On 04/12/2011 05:36 PM, Michal Suchanek wrote:
> >>>>
> >>>> On 12 April 2011 22:31, Ric Wheeler<ricwheeler@gmail.com>    wrote:
> >>>>>
> >>>>> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> as some already know the Unionmount VFS union which has been in
> >>>>>> development for some years now is the only True Union (TM) that can be
> >>>>>> accepted into the kernel mainline by the VFS maintainers (for reasons
> >>>>>> of their own which you can surely find if you search the web or ask
> >>>>>> them directly).
> >>>>>>
> >>>>>> The current UnionMount version that can be found here:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
> >>>>>>
> >>>>>> works for me as good as aufs does. That is I can build a live CD using
> >>>>>> this unioning solution and it boots and runs without any apparent
> >>>>>> issues.
> >>>>>>
> >>>>>> There are probably many possible uses of the union which I did not
> >>>>>> test nor did I test long term stability of using the unioned
> >>>>>> filesystem. As far as ephemeral live systems go it works fine for me,
> >>>>>> though.
> >>>>>>
> >>>>>> The issue is that while the code is (nearly) finished it is not yet
> >>>>>> merged into mainline and as I am not familiar with the details of
> >>>>>> ever-changing Linux VFS layer forward-porting this code to current
> >>>>>> kernels is somewhat challenging.
> >>>>>>
> >>>>>> What is the plan with unionmount now?
> >>>>>>
> >>>>>> What is required  for it to be merged into mainline?
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> Michal
> >>>>>
> >>>>> Hi Michal,
> >>>>>
> >>>>> People are actively looking to see what union mount (or overlayfs)
> >>>>> solution
> >>>>> to pursue. Val has shifted her focus away from kernel hacking these
> >>>>> days,
> >>>>> but did refresh her patch set in the last month or so.
> >>>>
> >>>> I am not aware of such refreshed patch set, at least it is not
> >>>> published in her repo.
> >>>>
> >>> Val posted the refreshed patches with the title on March 22nd:
> >>>
> >>> http://lwn.net/Articles/435019/
> >>>
> >> That article references the same four months old repo which I
> >> mentioned at the start of the thread, only a slightly different
> >> branch.
> >>
> >> While it maybe useful for testing unionmount (which I already tried)
> >> it is not a patch against current kernel which could be used to build
> >> current live images.
> >>
> >> Thanks
> >>
> >> Michal
> >
> > She did post the patch series that same date in March - you can probably
> > grab the series from linux-fsdevel, look for this series:
> >
> > "[PATCH 00/74] Union mounts version something or other"
> >
> > Al Viro was planning on looking at her refreshed patches (he had reviewed
> > them with her in person), but that is not going to happen any time soon so
> > getting more eyes and testing would be great!
> >
> 
> Even gmame can't collect the patches back from the ML, I don't want to try.
> 
> However, the discussion suggests that these are exactly the 4 months
> old branch ending in a commit with the summary "Temporary commit"
> which did not inspire confidence in me so I used the previous (also 4
> moths old) branch.

Yes, that's the impression I have too.

I believe David was working to update the patches and his silence
indicates he is probably bogged down with other priority work. If that's
the case, and your still interested, I might be able to help updating
the series some time soon. I haven't reviewed any of Val's series posts
for a while now so I'd need to catch up with the current state of the
project first.

I guess the first thing is to find out if David has made any progress,
David?

As for the overlayfs from Miklos I haven't looked closely at it but
since Miklos hasn't replied so far I'm guessing there's still a way to
with that as well.

Ian

Re: Unionmount status?

[Michal Suchanek]

On 13 April 2011 21:11, Ric Wheeler <ricwheeler@gmail.com> wrote:
> On 04/13/2011 02:58 PM, Michal Suchanek wrote:
>>
>> On 13 April 2011 19:26, Ric Wheeler<ricwheeler@gmail.com>  wrote:
>>>
>>> On 04/12/2011 05:36 PM, Michal Suchanek wrote:
>>>>
>>>> On 12 April 2011 22:31, Ric Wheeler<ricwheeler@gmail.com>    wrote:
>>>>>
>>>>> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> as some already know the Unionmount VFS union which has been in
>>>>>> development for some years now is the only True Union (TM) that can be
>>>>>> accepted into the kernel mainline by the VFS maintainers (for reasons
>>>>>> of their own which you can surely find if you search the web or ask
>>>>>> them directly).
>>>>>>
>>>>>> The current UnionMount version that can be found here:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>>>>>>
>>>>>> works for me as good as aufs does. That is I can build a live CD using
>>>>>> this unioning solution and it boots and runs without any apparent
>>>>>> issues.
>>>>>>
>>>>>> There are probably many possible uses of the union which I did not
>>>>>> test nor did I test long term stability of using the unioned
>>>>>> filesystem. As far as ephemeral live systems go it works fine for me,
>>>>>> though.
>>>>>>
>>>>>> The issue is that while the code is (nearly) finished it is not yet
>>>>>> merged into mainline and as I am not familiar with the details of
>>>>>> ever-changing Linux VFS layer forward-porting this code to current
>>>>>> kernels is somewhat challenging.
>>>>>>
>>>>>> What is the plan with unionmount now?
>>>>>>
>>>>>> What is required  for it to be merged into mainline?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Michal
>>>>>
>>>>> Hi Michal,
>>>>>
>>>>> People are actively looking to see what union mount (or overlayfs)
>>>>> solution
>>>>> to pursue. Val has shifted her focus away from kernel hacking these
>>>>> days,
>>>>> but did refresh her patch set in the last month or so.
>>>>
>>>> I am not aware of such refreshed patch set, at least it is not
>>>> published in her repo.
>>>>
>>> Val posted the refreshed patches with the title on March 22nd:
>>>
>>> http://lwn.net/Articles/435019/
>>>
>> That article references the same four months old repo which I
>> mentioned at the start of the thread, only a slightly different
>> branch.
>>
>> While it maybe useful for testing unionmount (which I already tried)
>> it is not a patch against current kernel which could be used to build
>> current live images.
>>
>> Thanks
>>
>> Michal
>
> She did post the patch series that same date in March - you can probably
> grab the series from linux-fsdevel, look for this series:
>
> "[PATCH 00/74] Union mounts version something or other"
>
> Al Viro was planning on looking at her refreshed patches (he had reviewed
> them with her in person), but that is not going to happen any time soon so
> getting more eyes and testing would be great!
>

Even gmame can't collect the patches back from the ML, I don't want to try.

However, the discussion suggests that these are exactly the 4 months
old branch ending in a commit with the summary "Temporary commit"
which did not inspire confidence in me so I used the previous (also 4
moths old) branch.

Thanks

Michal

Re: Unionmount status?

[Ric Wheeler]

On 04/13/2011 02:58 PM, Michal Suchanek wrote:
> On 13 April 2011 19:26, Ric Wheeler<ricwheeler@gmail.com>  wrote:
>> On 04/12/2011 05:36 PM, Michal Suchanek wrote:
>>> On 12 April 2011 22:31, Ric Wheeler<ricwheeler@gmail.com>    wrote:
>>>> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
>>>>> Hello,
>>>>>
>>>>> as some already know the Unionmount VFS union which has been in
>>>>> development for some years now is the only True Union (TM) that can be
>>>>> accepted into the kernel mainline by the VFS maintainers (for reasons
>>>>> of their own which you can surely find if you search the web or ask
>>>>> them directly).
>>>>>
>>>>> The current UnionMount version that can be found here:
>>>>>
>>>>>
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>>>>>
>>>>> works for me as good as aufs does. That is I can build a live CD using
>>>>> this unioning solution and it boots and runs without any apparent
>>>>> issues.
>>>>>
>>>>> There are probably many possible uses of the union which I did not
>>>>> test nor did I test long term stability of using the unioned
>>>>> filesystem. As far as ephemeral live systems go it works fine for me,
>>>>> though.
>>>>>
>>>>> The issue is that while the code is (nearly) finished it is not yet
>>>>> merged into mainline and as I am not familiar with the details of
>>>>> ever-changing Linux VFS layer forward-porting this code to current
>>>>> kernels is somewhat challenging.
>>>>>
>>>>> What is the plan with unionmount now?
>>>>>
>>>>> What is required  for it to be merged into mainline?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Michal
>>>> Hi Michal,
>>>>
>>>> People are actively looking to see what union mount (or overlayfs)
>>>> solution
>>>> to pursue. Val has shifted her focus away from kernel hacking these days,
>>>> but did refresh her patch set in the last month or so.
>>> I am not aware of such refreshed patch set, at least it is not
>>> published in her repo.
>>>
>> Val posted the refreshed patches with the title on March 22nd:
>>
>> http://lwn.net/Articles/435019/
>>
> That article references the same four months old repo which I
> mentioned at the start of the thread, only a slightly different
> branch.
>
> While it maybe useful for testing unionmount (which I already tried)
> it is not a patch against current kernel which could be used to build
> current live images.
>
> Thanks
>
> Michal

She did post the patch series that same date in March - you can probably grab 
the series from linux-fsdevel, look for this series:

"[PATCH 00/74] Union mounts version something or other"

Al Viro was planning on looking at her refreshed patches (he had reviewed them 
with her in person), but that is not going to happen any time soon so getting 
more eyes and testing would be great!

Ric

Re: Unionmount status?

[Michal Suchanek]

On 13 April 2011 19:26, Ric Wheeler <ricwheeler@gmail.com> wrote:
> On 04/12/2011 05:36 PM, Michal Suchanek wrote:
>>
>> On 12 April 2011 22:31, Ric Wheeler<ricwheeler@gmail.com>  wrote:
>>>
>>> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
>>>>
>>>> Hello,
>>>>
>>>> as some already know the Unionmount VFS union which has been in
>>>> development for some years now is the only True Union (TM) that can be
>>>> accepted into the kernel mainline by the VFS maintainers (for reasons
>>>> of their own which you can surely find if you search the web or ask
>>>> them directly).
>>>>
>>>> The current UnionMount version that can be found here:
>>>>
>>>>
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>>>>
>>>> works for me as good as aufs does. That is I can build a live CD using
>>>> this unioning solution and it boots and runs without any apparent
>>>> issues.
>>>>
>>>> There are probably many possible uses of the union which I did not
>>>> test nor did I test long term stability of using the unioned
>>>> filesystem. As far as ephemeral live systems go it works fine for me,
>>>> though.
>>>>
>>>> The issue is that while the code is (nearly) finished it is not yet
>>>> merged into mainline and as I am not familiar with the details of
>>>> ever-changing Linux VFS layer forward-porting this code to current
>>>> kernels is somewhat challenging.
>>>>
>>>> What is the plan with unionmount now?
>>>>
>>>> What is required  for it to be merged into mainline?
>>>>
>>>> Thanks
>>>>
>>>> Michal
>>>
>>> Hi Michal,
>>>
>>> People are actively looking to see what union mount (or overlayfs)
>>> solution
>>> to pursue. Val has shifted her focus away from kernel hacking these days,
>>> but did refresh her patch set in the last month or so.
>>
>> I am not aware of such refreshed patch set, at least it is not
>> published in her repo.
>>
>
> Val posted the refreshed patches with the title on March 22nd:
>
> http://lwn.net/Articles/435019/
>

That article references the same four months old repo which I
mentioned at the start of the thread, only a slightly different
branch.

While it maybe useful for testing unionmount (which I already tried)
it is not a patch against current kernel which could be used to build
current live images.

Thanks

Michal

Re: Unionmount status?

[Ric Wheeler]

On 04/12/2011 05:36 PM, Michal Suchanek wrote:
> On 12 April 2011 22:31, Ric Wheeler<ricwheeler@gmail.com>  wrote:
>> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
>>> Hello,
>>>
>>> as some already know the Unionmount VFS union which has been in
>>> development for some years now is the only True Union (TM) that can be
>>> accepted into the kernel mainline by the VFS maintainers (for reasons
>>> of their own which you can surely find if you search the web or ask
>>> them directly).
>>>
>>> The current UnionMount version that can be found here:
>>>
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>>>
>>> works for me as good as aufs does. That is I can build a live CD using
>>> this unioning solution and it boots and runs without any apparent
>>> issues.
>>>
>>> There are probably many possible uses of the union which I did not
>>> test nor did I test long term stability of using the unioned
>>> filesystem. As far as ephemeral live systems go it works fine for me,
>>> though.
>>>
>>> The issue is that while the code is (nearly) finished it is not yet
>>> merged into mainline and as I am not familiar with the details of
>>> ever-changing Linux VFS layer forward-porting this code to current
>>> kernels is somewhat challenging.
>>>
>>> What is the plan with unionmount now?
>>>
>>> What is required  for it to be merged into mainline?
>>>
>>> Thanks
>>>
>>> Michal
>> Hi Michal,
>>
>> People are actively looking to see what union mount (or overlayfs) solution
>> to pursue. Val has shifted her focus away from kernel hacking these days,
>> but did refresh her patch set in the last month or so.
> I am not aware of such refreshed patch set, at least it is not
> published in her repo.
>

Val posted the refreshed patches with the title on March 22nd:

http://lwn.net/Articles/435019/

Ric

>> Miklos has an overlay file system that has also been posted upstream.
> I have no idea about his other overlay filesystem either.
>
>> I think that testing like you did and getting more eyes to look at the code
>> is the next key step for both projects.
>>
> Could you provide more details?
>
> I am not following the Linux fs development closely.
>
> Thanks
>
> Michal

Re: Unionmount status?

[Michal Suchanek]

On 13 April 2011 16:18, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 12 Apr 2011, Michal Suchanek wrote:
>
>> > Miklos has an overlay file system that has also been posted upstream.
>>
>> I have no idea about his other overlay filesystem either.
>
> https://lkml.org/lkml/2011/3/22/222
>

Thanks for pointing out this announcement.

However, neither this announcement nor the document
Documentation/filesystems/overlayfs.txt included in the git tree
details how to mount the filesystem. Without that it is kind of
useless.

Thanks

Michal

Re: Unionmount status?

[Jiri Kosina]

On Tue, 12 Apr 2011, Michal Suchanek wrote:

> > Miklos has an overlay file system that has also been posted upstream.
> 
> I have no idea about his other overlay filesystem either.

https://lkml.org/lkml/2011/3/22/222

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: Unionmount status?

[Michal Suchanek]

On 12 April 2011 22:31, Ric Wheeler <ricwheeler@gmail.com> wrote:
> On 04/12/2011 11:00 AM, Michal Suchanek wrote:
>>
>> Hello,
>>
>> as some already know the Unionmount VFS union which has been in
>> development for some years now is the only True Union (TM) that can be
>> accepted into the kernel mainline by the VFS maintainers (for reasons
>> of their own which you can surely find if you search the web or ask
>> them directly).
>>
>> The current UnionMount version that can be found here:
>>
>>
>> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>>
>> works for me as good as aufs does. That is I can build a live CD using
>> this unioning solution and it boots and runs without any apparent
>> issues.
>>
>> There are probably many possible uses of the union which I did not
>> test nor did I test long term stability of using the unioned
>> filesystem. As far as ephemeral live systems go it works fine for me,
>> though.
>>
>> The issue is that while the code is (nearly) finished it is not yet
>> merged into mainline and as I am not familiar with the details of
>> ever-changing Linux VFS layer forward-porting this code to current
>> kernels is somewhat challenging.
>>
>> What is the plan with unionmount now?
>>
>> What is required  for it to be merged into mainline?
>>
>> Thanks
>>
>> Michal
>
> Hi Michal,
>
> People are actively looking to see what union mount (or overlayfs) solution
> to pursue. Val has shifted her focus away from kernel hacking these days,
> but did refresh her patch set in the last month or so.

I am not aware of such refreshed patch set, at least it is not
published in her repo.

>
> Miklos has an overlay file system that has also been posted upstream.

I have no idea about his other overlay filesystem either.

>
> I think that testing like you did and getting more eyes to look at the code
> is the next key step for both projects.
>

Could you provide more details?

I am not following the Linux fs development closely.

Thanks

Michal

Re: Unionmount status?

[Ric Wheeler]

On 04/12/2011 11:00 AM, Michal Suchanek wrote:
> Hello,
>
> as some already know the Unionmount VFS union which has been in
> development for some years now is the only True Union (TM) that can be
> accepted into the kernel mainline by the VFS maintainers (for reasons
> of their own which you can surely find if you search the web or ask
> them directly).
>
> The current UnionMount version that can be found here:
>
> http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works
>
> works for me as good as aufs does. That is I can build a live CD using
> this unioning solution and it boots and runs without any apparent
> issues.
>
> There are probably many possible uses of the union which I did not
> test nor did I test long term stability of using the unioned
> filesystem. As far as ephemeral live systems go it works fine for me,
> though.
>
> The issue is that while the code is (nearly) finished it is not yet
> merged into mainline and as I am not familiar with the details of
> ever-changing Linux VFS layer forward-porting this code to current
> kernels is somewhat challenging.
>
> What is the plan with unionmount now?
>
> What is required  for it to be merged into mainline?
>
> Thanks
>
> Michal

Hi Michal,

People are actively looking to see what union mount (or overlayfs) solution to 
pursue. Val has shifted her focus away from kernel hacking these days, but did 
refresh her patch set in the last month or so.

Miklos has an overlay file system that has also been posted upstream.

I think that testing like you did and getting more eyes to look at the code is 
the next key step for both projects.

Thanks!

Ric

Unionmount status?

[Michal Suchanek]

Hello,

as some already know the Unionmount VFS union which has been in
development for some years now is the only True Union (TM) that can be
accepted into the kernel mainline by the VFS maintainers (for reasons
of their own which you can surely find if you search the web or ask
them directly).

The current UnionMount version that can be found here:

http://git.kernel.org/?p=linux/kernel/git/val/linux-2.6.git;a=shortlog;h=refs/heads/ext2_works

works for me as good as aufs does. That is I can build a live CD using
this unioning solution and it boots and runs without any apparent
issues.

There are probably many possible uses of the union which I did not
test nor did I test long term stability of using the unioned
filesystem. As far as ephemeral live systems go it works fine for me,
though.

The issue is that while the code is (nearly) finished it is not yet
merged into mainline and as I am not familiar with the details of
ever-changing Linux VFS layer forward-porting this code to current
kernels is somewhat challenging.

What is the plan with unionmount now?

What is required  for it to be merged into mainline?

Thanks

Michal