* UnionMount status? @ 2010-03-19 0:21 Michal Suchanek 2010-03-19 6:10 ` J. R. Okajima 2010-03-19 18:03 ` Valerie Aurora 0 siblings, 2 replies; 55+ messages in thread From: Michal Suchanek @ 2010-03-19 0:21 UTC (permalink / raw) To: linux-fsdevel; +Cc: vaurora 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 0:21 UnionMount status? Michal Suchanek @ 2010-03-19 6:10 ` J. R. Okajima 2010-03-19 20:28 ` Michal Suchanek 2010-03-19 18:03 ` Valerie Aurora 1 sibling, 1 reply; 55+ messages in thread From: J. R. Okajima @ 2010-03-19 6:10 UTC (permalink / raw) To: Michal Suchanek; +Cc: linux-fsdevel, vaurora 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 6:10 ` J. R. Okajima @ 2010-03-19 20:28 ` Michal Suchanek 2010-03-19 20:59 ` J. R. Okajima 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2010-03-19 20:28 UTC (permalink / raw) To: J. R. Okajima; +Cc: linux-fsdevel, vaurora 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 20:28 ` Michal Suchanek @ 2010-03-19 20:59 ` J. R. Okajima 0 siblings, 0 replies; 55+ messages in thread From: J. R. Okajima @ 2010-03-19 20:59 UTC (permalink / raw) To: Michal Suchanek; +Cc: linux-fsdevel, vaurora 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 0:21 UnionMount status? Michal Suchanek 2010-03-19 6:10 ` J. R. Okajima @ 2010-03-19 18:03 ` Valerie Aurora 2010-03-19 21:47 ` Michal Suchanek 2010-07-12 13:01 ` Michal Suchanek 1 sibling, 2 replies; 55+ messages in thread From: Valerie Aurora @ 2010-03-19 18:03 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 18:03 ` Valerie Aurora @ 2010-03-19 21:47 ` Michal Suchanek 2010-03-20 16:41 ` Michal Suchanek ` (2 more replies) 2010-07-12 13:01 ` Michal Suchanek 1 sibling, 3 replies; 55+ messages in thread From: Michal Suchanek @ 2010-03-19 21:47 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 21:47 ` Michal Suchanek @ 2010-03-20 16:41 ` Michal Suchanek 2010-03-23 23:02 ` Valerie Aurora 2010-07-14 13:12 ` Michal Suchanek 2 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2010-03-20 16:41 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 21:47 ` Michal Suchanek 2010-03-20 16:41 ` Michal Suchanek @ 2010-03-23 23:02 ` Valerie Aurora 2010-04-01 15:36 ` Michal Suchanek 2010-07-14 13:12 ` Michal Suchanek 2 siblings, 1 reply; 55+ messages in thread From: Valerie Aurora @ 2010-03-23 23:02 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-23 23:02 ` Valerie Aurora @ 2010-04-01 15:36 ` Michal Suchanek 0 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2010-04-01 15:36 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 21:47 ` Michal Suchanek 2010-03-20 16:41 ` Michal Suchanek 2010-03-23 23:02 ` Valerie Aurora @ 2010-07-14 13:12 ` Michal Suchanek 2010-07-14 19:30 ` Valerie Aurora 2 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2010-07-14 13:12 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-07-14 13:12 ` Michal Suchanek @ 2010-07-14 19:30 ` Valerie Aurora 2010-07-19 16:06 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Valerie Aurora @ 2010-07-14 19:30 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-07-14 19:30 ` Valerie Aurora @ 2010-07-19 16:06 ` Michal Suchanek 2010-08-10 16:52 ` Valerie Aurora 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2010-07-19 16:06 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-07-19 16:06 ` Michal Suchanek @ 2010-08-10 16:52 ` Valerie Aurora [not found] ` <AANLkTik+S2femtfOQvAYMayfN2N=PGvVL8J9=AD3_VCa@mail.gmail.com> 0 siblings, 1 reply; 55+ messages in thread From: Valerie Aurora @ 2010-08-10 16:52 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
[parent not found: <AANLkTik+S2femtfOQvAYMayfN2N=PGvVL8J9=AD3_VCa@mail.gmail.com>]
* Re: UnionMount status? [not found] ` <AANLkTik+S2femtfOQvAYMayfN2N=PGvVL8J9=AD3_VCa@mail.gmail.com> @ 2010-08-16 18:52 ` Valerie Aurora 2010-08-17 12:03 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Valerie Aurora @ 2010-08-16 18:52 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-08-16 18:52 ` Valerie Aurora @ 2010-08-17 12:03 ` Michal Suchanek 2010-08-17 14:31 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2010-08-17 12:03 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-08-17 12:03 ` Michal Suchanek @ 2010-08-17 14:31 ` Michal Suchanek 2010-08-17 19:51 ` Valerie Aurora 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2010-08-17 14:31 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-08-17 14:31 ` Michal Suchanek @ 2010-08-17 19:51 ` Valerie Aurora 2010-08-18 11:30 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Valerie Aurora @ 2010-08-17 19:51 UTC (permalink / raw) To: Michal Suchanek; +Cc: linux-fsdevel 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-08-17 19:51 ` Valerie Aurora @ 2010-08-18 11:30 ` Michal Suchanek 2010-08-18 19:06 ` Valerie Aurora 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2010-08-18 11:30 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-fsdevel 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-08-18 11:30 ` Michal Suchanek @ 2010-08-18 19:06 ` Valerie Aurora 2010-08-18 19:25 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Valerie Aurora @ 2010-08-18 19:06 UTC (permalink / raw) To: Michal Suchanek; +Cc: linux-fsdevel 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-08-18 19:06 ` Valerie Aurora @ 2010-08-18 19:25 ` Michal Suchanek 0 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2010-08-18 19:25 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-fsdevel 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: UnionMount status? 2010-03-19 18:03 ` Valerie Aurora 2010-03-19 21:47 ` Michal Suchanek @ 2010-07-12 13:01 ` Michal Suchanek 1 sibling, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2010-07-12 13:01 UTC (permalink / raw) To: Valerie Aurora Cc: linux-fsdevel, Alexander Viro, Nick Piggin, Dmitry Monakhov, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Unionmount status? @ 2011-04-12 15:00 Michal Suchanek 2011-04-12 20:31 ` Ric Wheeler 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-12 15:00 UTC (permalink / raw) To: linux-fsdevel, linux-kernel 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-12 15:00 Unionmount status? Michal Suchanek @ 2011-04-12 20:31 ` Ric Wheeler 2011-04-12 21:36 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Ric Wheeler @ 2011-04-12 20:31 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-12 20:31 ` Ric Wheeler @ 2011-04-12 21:36 ` Michal Suchanek 2011-04-13 14:18 ` Jiri Kosina 2011-04-13 17:26 ` Ric Wheeler 0 siblings, 2 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-12 21:36 UTC (permalink / raw) To: Ric Wheeler Cc: linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-12 21:36 ` Michal Suchanek @ 2011-04-13 14:18 ` Jiri Kosina 2011-04-13 15:13 ` Michal Suchanek 2011-04-13 17:26 ` Ric Wheeler 1 sibling, 1 reply; 55+ messages in thread From: Jiri Kosina @ 2011-04-13 14:18 UTC (permalink / raw) To: Michal Suchanek Cc: Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 14:18 ` Jiri Kosina @ 2011-04-13 15:13 ` Michal Suchanek 2011-04-14 8:38 ` Miklos Szeredi 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-13 15:13 UTC (permalink / raw) To: Jiri Kosina Cc: Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 15:13 ` Michal Suchanek @ 2011-04-14 8:38 ` Miklos Szeredi 2011-04-14 9:48 ` Sedat Dilek 2011-04-15 11:22 ` Michal Suchanek 0 siblings, 2 replies; 55+ messages in thread From: Miklos Szeredi @ 2011-04-14 8:38 UTC (permalink / raw) To: Michal Suchanek Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 8:38 ` Miklos Szeredi @ 2011-04-14 9:48 ` Sedat Dilek 2011-04-14 9:58 ` Miklos Szeredi 2011-04-15 11:22 ` Michal Suchanek 1 sibling, 1 reply; 55+ messages in thread From: Sedat Dilek @ 2011-04-14 9:48 UTC (permalink / raw) To: Miklos Szeredi Cc: Michal Suchanek, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 - ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 9:48 ` Sedat Dilek @ 2011-04-14 9:58 ` Miklos Szeredi 0 siblings, 0 replies; 55+ messages in thread From: Miklos Szeredi @ 2011-04-14 9:58 UTC (permalink / raw) To: sedat.dilek Cc: Sedat Dilek, Michal Suchanek, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 8:38 ` Miklos Szeredi 2011-04-14 9:48 ` Sedat Dilek @ 2011-04-15 11:22 ` Michal Suchanek 2011-04-15 11:31 ` Miklos Szeredi 1 sibling, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-15 11:22 UTC (permalink / raw) To: Miklos Szeredi Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 11:22 ` Michal Suchanek @ 2011-04-15 11:31 ` Miklos Szeredi 2011-04-15 11:51 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Miklos Szeredi @ 2011-04-15 11:31 UTC (permalink / raw) To: Michal Suchanek Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 11:31 ` Miklos Szeredi @ 2011-04-15 11:51 ` Michal Suchanek 2011-04-15 12:29 ` Miklos Szeredi 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-15 11:51 UTC (permalink / raw) To: Miklos Szeredi Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 11:51 ` Michal Suchanek @ 2011-04-15 12:29 ` Miklos Szeredi 2011-04-15 12:34 ` Michal Suchanek ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Miklos Szeredi @ 2011-04-15 12:29 UTC (permalink / raw) To: Michal Suchanek Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 12:29 ` Miklos Szeredi @ 2011-04-15 12:34 ` Michal Suchanek 2011-04-15 21:48 ` Hugh Dickins 2011-04-15 22:18 ` Andreas Dilger 2 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-15 12:34 UTC (permalink / raw) To: Miklos Szeredi Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? @ 2011-04-15 12:34 ` Michal Suchanek 0 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-15 12:34 UTC (permalink / raw) To: Miklos Szeredi Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 12:34 ` Michal Suchanek (?) @ 2011-04-15 12:48 ` Miklos Szeredi -1 siblings, 0 replies; 55+ messages in thread From: Miklos Szeredi @ 2011-04-15 12:48 UTC (permalink / raw) To: Michal Suchanek Cc: Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 12:29 ` Miklos Szeredi 2011-04-15 12:34 ` Michal Suchanek @ 2011-04-15 21:48 ` Hugh Dickins 2011-04-15 22:18 ` Andreas Dilger 2 siblings, 0 replies; 55+ messages in thread From: Hugh Dickins @ 2011-04-15 21:48 UTC (permalink / raw) To: Miklos Szeredi Cc: Michal Suchanek, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig, Eric Paris, James Morris 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 12:29 ` Miklos Szeredi 2011-04-15 12:34 ` Michal Suchanek 2011-04-15 21:48 ` Hugh Dickins @ 2011-04-15 22:18 ` Andreas Dilger 2011-04-18 13:31 ` Michal Suchanek ` (2 more replies) 2 siblings, 3 replies; 55+ messages in thread From: Andreas Dilger @ 2011-04-15 22:18 UTC (permalink / raw) To: Miklos Szeredi Cc: Michal Suchanek, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 22:18 ` Andreas Dilger @ 2011-04-18 13:31 ` Michal Suchanek 2011-04-18 13:34 ` Michal Suchanek 2011-04-18 13:37 ` Michal Suchanek 2 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-18 13:31 UTC (permalink / raw) To: Andreas Dilger Cc: Miklos Szeredi, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? @ 2011-04-18 13:31 ` Michal Suchanek 0 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-18 13:31 UTC (permalink / raw) To: Andreas Dilger Cc: Miklos Szeredi, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 22:18 ` Andreas Dilger @ 2011-04-18 13:34 ` Michal Suchanek 2011-04-18 13:34 ` Michal Suchanek 2011-04-18 13:37 ` Michal Suchanek 2 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-18 13:34 UTC (permalink / raw) To: Andreas Dilger Cc: Miklos Szeredi, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? @ 2011-04-18 13:34 ` Michal Suchanek 0 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-18 13:34 UTC (permalink / raw) To: Andreas Dilger Cc: Miklos Szeredi, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-15 22:18 ` Andreas Dilger @ 2011-04-18 13:37 ` Michal Suchanek 2011-04-18 13:34 ` Michal Suchanek 2011-04-18 13:37 ` Michal Suchanek 2 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-18 13:37 UTC (permalink / raw) To: Andreas Dilger Cc: Miklos Szeredi, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? @ 2011-04-18 13:37 ` Michal Suchanek 0 siblings, 0 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-18 13:37 UTC (permalink / raw) To: Andreas Dilger Cc: Miklos Szeredi, Jiri Kosina, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-12 21:36 ` Michal Suchanek 2011-04-13 14:18 ` Jiri Kosina @ 2011-04-13 17:26 ` Ric Wheeler 2011-04-13 18:58 ` Michal Suchanek 1 sibling, 1 reply; 55+ messages in thread From: Ric Wheeler @ 2011-04-13 17:26 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 17:26 ` Ric Wheeler @ 2011-04-13 18:58 ` Michal Suchanek 2011-04-13 19:11 ` Ric Wheeler 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-13 18:58 UTC (permalink / raw) To: Ric Wheeler Cc: linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 18:58 ` Michal Suchanek @ 2011-04-13 19:11 ` Ric Wheeler 2011-04-13 19:47 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Ric Wheeler @ 2011-04-13 19:11 UTC (permalink / raw) To: Michal Suchanek Cc: linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 19:11 ` Ric Wheeler @ 2011-04-13 19:47 ` Michal Suchanek 2011-04-14 4:50 ` Ian Kent 2011-04-14 19:14 ` David Howells 0 siblings, 2 replies; 55+ messages in thread From: Michal Suchanek @ 2011-04-13 19:47 UTC (permalink / raw) To: Ric Wheeler Cc: linux-fsdevel, linux-kernel, David Howells, Ian Kent, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 19:47 ` Michal Suchanek @ 2011-04-14 4:50 ` Ian Kent 2011-04-14 9:32 ` Michal Suchanek 2011-04-14 19:14 ` David Howells 1 sibling, 1 reply; 55+ messages in thread From: Ian Kent @ 2011-04-14 4:50 UTC (permalink / raw) To: Michal Suchanek Cc: Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 4:50 ` Ian Kent @ 2011-04-14 9:32 ` Michal Suchanek 2011-04-14 9:40 ` Miklos Szeredi 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-14 9:32 UTC (permalink / raw) To: Ian Kent Cc: Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 9:32 ` Michal Suchanek @ 2011-04-14 9:40 ` Miklos Szeredi 2011-04-14 13:21 ` Ric Wheeler 0 siblings, 1 reply; 55+ messages in thread From: Miklos Szeredi @ 2011-04-14 9:40 UTC (permalink / raw) To: Michal Suchanek Cc: Ian Kent, Ric Wheeler, linux-fsdevel, linux-kernel, David Howells, Jeff Moyer, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 9:40 ` Miklos Szeredi @ 2011-04-14 13:21 ` Ric Wheeler 2011-04-14 14:54 ` Michal Suchanek 0 siblings, 1 reply; 55+ messages in thread From: Ric Wheeler @ 2011-04-14 13:21 UTC (permalink / raw) To: Miklos Szeredi, Christoph Hellwig Cc: Michal Suchanek, Ian Kent, linux-fsdevel, linux-kernel, David Howells, Jeff Moyer 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 13:21 ` Ric Wheeler @ 2011-04-14 14:54 ` Michal Suchanek 2011-04-15 16:31 ` Ric Wheeler 0 siblings, 1 reply; 55+ messages in thread From: Michal Suchanek @ 2011-04-14 14:54 UTC (permalink / raw) To: Ric Wheeler Cc: Miklos Szeredi, Christoph Hellwig, Ian Kent, linux-fsdevel, linux-kernel, David Howells, Jeff Moyer 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-14 14:54 ` Michal Suchanek @ 2011-04-15 16:31 ` Ric Wheeler 0 siblings, 0 replies; 55+ messages in thread From: Ric Wheeler @ 2011-04-15 16:31 UTC (permalink / raw) To: Michal Suchanek Cc: Miklos Szeredi, Christoph Hellwig, Ian Kent, linux-fsdevel, linux-kernel, David Howells, Jeff Moyer 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Unionmount status? 2011-04-13 19:47 ` Michal Suchanek 2011-04-14 4:50 ` Ian Kent @ 2011-04-14 19:14 ` David Howells 1 sibling, 0 replies; 55+ messages in thread From: David Howells @ 2011-04-14 19:14 UTC (permalink / raw) To: Ian Kent Cc: dhowells, Michal Suchanek, Ric Wheeler, linux-fsdevel, linux-kernel, Jeff Moyer, miklos, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2011-04-18 13:38 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-19 0:21 UnionMount status? Michal Suchanek 2010-03-19 6:10 ` J. R. Okajima 2010-03-19 20:28 ` Michal Suchanek 2010-03-19 20:59 ` J. R. Okajima 2010-03-19 18:03 ` Valerie Aurora 2010-03-19 21:47 ` Michal Suchanek 2010-03-20 16:41 ` Michal Suchanek 2010-03-23 23:02 ` Valerie Aurora 2010-04-01 15:36 ` Michal Suchanek 2010-07-14 13:12 ` Michal Suchanek 2010-07-14 19:30 ` Valerie Aurora 2010-07-19 16:06 ` Michal Suchanek 2010-08-10 16:52 ` Valerie Aurora [not found] ` <AANLkTik+S2femtfOQvAYMayfN2N=PGvVL8J9=AD3_VCa@mail.gmail.com> 2010-08-16 18:52 ` Valerie Aurora 2010-08-17 12:03 ` Michal Suchanek 2010-08-17 14:31 ` Michal Suchanek 2010-08-17 19:51 ` Valerie Aurora 2010-08-18 11:30 ` Michal Suchanek 2010-08-18 19:06 ` Valerie Aurora 2010-08-18 19:25 ` Michal Suchanek 2010-07-12 13:01 ` Michal Suchanek 2011-04-12 15:00 Unionmount status? Michal Suchanek 2011-04-12 20:31 ` Ric Wheeler 2011-04-12 21:36 ` Michal Suchanek 2011-04-13 14:18 ` Jiri Kosina 2011-04-13 15:13 ` Michal Suchanek 2011-04-14 8:38 ` Miklos Szeredi 2011-04-14 9:48 ` Sedat Dilek 2011-04-14 9:58 ` Miklos Szeredi 2011-04-15 11:22 ` Michal Suchanek 2011-04-15 11:31 ` Miklos Szeredi 2011-04-15 11:51 ` Michal Suchanek 2011-04-15 12:29 ` Miklos Szeredi 2011-04-15 12:34 ` Michal Suchanek 2011-04-15 12:34 ` Michal Suchanek 2011-04-15 12:48 ` Miklos Szeredi 2011-04-15 21:48 ` Hugh Dickins 2011-04-15 22:18 ` Andreas Dilger 2011-04-18 13:31 ` Michal Suchanek 2011-04-18 13:31 ` Michal Suchanek 2011-04-18 13:34 ` Michal Suchanek 2011-04-18 13:34 ` Michal Suchanek 2011-04-18 13:37 ` Michal Suchanek 2011-04-18 13:37 ` Michal Suchanek 2011-04-13 17:26 ` Ric Wheeler 2011-04-13 18:58 ` Michal Suchanek 2011-04-13 19:11 ` Ric Wheeler 2011-04-13 19:47 ` Michal Suchanek 2011-04-14 4:50 ` Ian Kent 2011-04-14 9:32 ` Michal Suchanek 2011-04-14 9:40 ` Miklos Szeredi 2011-04-14 13:21 ` Ric Wheeler 2011-04-14 14:54 ` Michal Suchanek 2011-04-15 16:31 ` Ric Wheeler 2011-04-14 19:14 ` David Howells
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.