Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Linus Torvalds:
> Yes. That would be lovely. And trivial for most filesystems to support.
>
> Sure, you could have an inode if you need to (not all filesystems may
> have a flag in the directory entry), so it would look like "mknod()"
> for the filesystem. But the filesystem might decide to never actually
> create the inode at all if it reconizes the node as a whiteout node.

I am not sure whether it is trivial for FS developers. But I agree that
it is the maintainer who can decide the most suitable method to whiteout
for that FS.


> Also note that it's only the "upper layer" filesystem that needs
> whiteout nodes. So it's not "all filesystems involved with overlayfs",
> it's only the upper ones. And they have to already support xattr, so
> I'm assuming in practice we're talking only a few cases, right? Just
> tmpfs, ext3, ext4 probably covers most cases..

I agree that tmpfs is majority.
In real world, people uses various fs as the upper RW layer. NFS is
popular too. Sometimes non-mainlined FSs are used such as glusterfs. In
the long history of aufs1 to aufs3, there have been xfs, smbfs, fuse,
ubifs and fat/vfat are used as far as I remember. (though I am not sure
users still use them)
It means that the unioning is used in various way of long-live systems,
not only on the short-live LiveCD systems.

And there are a use-case which uses aufs like a version control
system. For example,
- /aufs = /rw1 + /ro0
- all the changes are stored under /rw1.
- prepend a new top layer and set /rw1 readonly,
  /aufs = /rw2 + /ro1 (which was /rw1) + /ro0
- now /ro1 holds the past changes and later changes are all go to /rw2.
- on the next day/week/month,
  /aufs = /rw3 + /ro2 (which was /rw2) + /ro1 (which as /rw1) + /ro0

As a variation, there is a merging approach. It means moving files from
the upper RW to the lower RO and creates a new RO. In this variation,
the number of layers will not change.

Ah, I should have mentioned the difference between overlayfs and aufs.
- aufs supports muliple layers more than 2.
- direct access to the layers (bypassing aufs) is allowed.

If the underlying FS chooses the way to introduce a new d_type to
implement whiteout, then many applications have to support it. And the
above merging approach (or backup) will not be used until the
application completes supporting. When the FS is a network filesystem,
the new d_type has to be available on both of server and client. Of
course, the server may be other than linux. Even if FS is local, users
may setup dual-boot. And the other OS has to recognize the new d_type
value.
I still doubt it is a good approach.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Al Viro:
> Sure - btrfs happens to have an interesting limit on the number of
> links to the same object located in one directory.

It doesn't matter.
On every filesystem, the link count has its upper limit eventually. When
vfs_link() for whiteout returns EMLINK, aufs removes the whiteout-src
file and creates a new one internally and asynchronously. Completing a
new whiteout-src, aufs will go back to the link approach. The actual
link count when EMLINK returned does not matter.

Some filesystems don't support link(2). For such fs, user should tell
aufs that the layer-fs has no link, and aufs will always create whiteout
as a size-zeroed regular file instead of hardlink. Otherwise user cannot
remove a file logically (rm(1) will return ENOTSUP or EPERM.).


> And yes, it is an independent primitive.  What I really don't understand
> is WTF is so attractive about not having to touch individual filesystems;
> it's not particulary hard to do for any fs we might care about...

Hmm, aufs might have lived too long time as outside mainline. The
whiteout approach aufs took is non-modifying the underlying fs. And I
thought it is essentially important for new fs, otherwise it would be
harder to be merged.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Sat, Mar 16, 2013 at 03:57:18AM +0900, J. R. Okajima wrote:
> 
> Al Viro:
> > The trouble with such mechanisms is that they tend to end up depending on
> > fairly non-trivial properties of underlying fs.  Try aufs one on btrfs,
> > see how soon you spot the problem.  It's nice when a method turns out
> > to be really redundant and implementable in uniform way via other methods
> > present; see fh_to_dentry history for example of situation where it 
> > hadn't...
> 
> Hmm, I could not see problem around aufs using btrfs as the upper RW
> branch, tested on linux-3.9-rc2.
> Would you describe more specifically?

Sure - btrfs happens to have an interesting limit on the number of
links to the same object located in one directory.

The thing is, you are trying to retrofit a new primitive into many
filesystems and do it in the same way.  Doesn't work well...

And yes, it is an independent primitive.  What I really don't understand
is WTF is so attractive about not having to touch individual filesystems;
it's not particulary hard to do for any fs we might care about...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Erez Zadok]

I tend to agree with Al's and Linus's POV regarding whiteouts. There are three 
general techniques to implementing whiteouts:

1. namespace: special file names, hard/symlinks, or special "hidden" dot files.
2. extended attributes.
3. DT_WHT dirent flags.
(there's actually a 4th method I've tried before that I won't discuss below: 
implementing your own data structures on a raw partition — way too cumbersome.)

The namespace techniques require lower file systems to support hard/symlinks 
and sometimes need long names. A plus: they work on most file systems (but not 
all).  But they cause all sorts of namespace ugliness, where you have to hide 
the special file names, avoid them, ensure atomic updates for ops that involve 
whiteouts.  It's all doable, as had been demonstrated by several 
implementations.  But it's still icky in terms of namespace pollution.

The extended attributes technique, I think, is better than the namespace one in 
that you don't pollute the namespace; plus, I think the EA technique minimizes 
atomicity issues that show up with the namespace method.  Yet, it still 
requires EA support in lower file systems, so it won't work unless lower file 
systems support xattr ops.  Plus it could fail for file systems that have 
limited xattr support (e.g., number of EAs per inode).

The DT_WHT technique is the cleanest in the long run, and the best of the three 
IMHO.  It's well understood and has been done in BSD a long time ago.  It 
doesn't have the namespace pollution as seen in technique #1 above.  And I 
believe it also minimize atomicity issues.  Plus you won't have issues running 
out of EAs.

A while back I've looked at the unionmount code for DT_WHT support for 
ext2/tmpfs, and it was small, clean, and mostly additive.  I even had a 
prototype port of unionfs using unionmount's DT_WHT support: it was relatively 
easy to port unionfs to use DT_WHT instead of namespace techniques. Plus, I was 
able to reduce the amount of code devoted to whiteout support by quite a bit.

So I think it'll be easy to port overlayfs to use DT_WHT.  Given that most 
people use unioning with ext* and tmpfs, minimal DT_WHT support in those would 
get most users happy initially. And we can then let other file systems support 
DT_WHT on their own, in whatever way they deem suitable (as Al suggested, this 
is really best deferred to the F/S to implement).

Lastly, what I'm not sure is what API to use for whiteouts: should every f/s 
implement some new methods to add/remove/query a whiteout, or should the upper 
f/s and VFS directly check DT_WHT flags with S_ISWHT.  The generic f/s methods 
may allow file systems to implement whiteouts in arbitrary ways, not 
necessarily as a dirent flag.

Cheers,
Erez.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Linus Torvalds]

On Thu, Mar 14, 2013 at 10:09 PM, J. R. Okajima  wrote:
>
> "no inodes at all"?
> Are you assuming the implementation in dcache only (with a new d_type
> flag)? And it is up to the real fs (layer or branch) whether it consumes
> inode or not?

Yes. That would be lovely. And trivial for most filesystems to support.

Sure, you could have an inode if you need to (not all filesystems may
have a flag in the directory entry), so it would look like "mknod()"
for the filesystem. But the filesystem might decide to never actually
create the inode at all if it reconizes the node as a whiteout node.

I think we should do this. Yes, it requires filesystem work, but in
the long run it's the right thing to do, and the filesystem work is
likely very very simple. Besides, we probably only need to support a
few filesystems for it to be already useful. What filesystems do the
people who use unionfs actually use today?

Also note that it's only the "upper layer" filesystem that needs
whiteout nodes. So it's not "all filesystems involved with overlayfs",
it's only the upper ones. And they have to already support xattr, so
I'm assuming in practice we're talking only a few cases, right? Just
tmpfs, ext3, ext4 probably covers most cases..

And it would get rid of all the horrible security check changes for
xattrs, no? So we'd really end up with a noticeably cleaner model.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Al Viro:
> The trouble with such mechanisms is that they tend to end up depending on
> fairly non-trivial properties of underlying fs.  Try aufs one on btrfs,
> see how soon you spot the problem.  It's nice when a method turns out
> to be really redundant and implementable in uniform way via other methods
> present; see fh_to_dentry history for example of situation where it hadn't...

Hmm, I could not see problem around aufs using btrfs as the upper RW
branch, tested on linux-3.9-rc2.
Would you describe more specifically?
Some of my local tests didn't pass due to an error return from
btrfs. For example, repeat "ln fileA $very_lng_filename", then btrfs
returns EMLINK so soon.

And aufs refers the common set of inode attribute. I mean attrs declared
in VFS. Also I know some filesystems don't maintain attrs on each
operation. For such fs, aufs calls vfs_getattr() internally.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Fri, Mar 15, 2013 at 08:15:18AM +, James Bottomley wrote:

> It's the fact that a directory entry based whiteout limits the amount of
> change to the VFS, but has to be supported by underlying filesystems.
> The generic_dirent_fallthrough() mechanism is a nice way of hiding it,
> but there are still quite a few fs specific mods in the union mount tree
> because of this.  Having to modify filesystems to me indicates the
> mechanism is a bit fragile.  If we could do whiteouts purely in the VFS,
> so it would work for any filesystem (without needing filesystem
> modifications) that would seem to be a more robust approach.  I'm not
> saying we can definitely do this in an elegant way ... I'm just saying
> that if someone comes up with it, it's obviously preferable.

The trouble with such mechanisms is that they tend to end up depending on
fairly non-trivial properties of underlying fs.  Try aufs one on btrfs,
see how soon you spot the problem.  It's nice when a method turns out
to be really redundant and implementable in uniform way via other methods
present; see fh_to_dentry history for example of situation where it hadn't...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[James Bottomley]

On Fri, 2013-03-15 at 05:13 +, Al Viro wrote:
> On Fri, Mar 15, 2013 at 02:09:14PM +0900, J. R. Okajima wrote:
> 
> > If so, it has a big disadvantage for the layer-fs (or branch-fs) to have
> > to implement a new method for whiteout.
> > 
> > Overlayfs implements whiteout as symlink+xattr which consumes an
> > inode. And you don't like it, right?
> > What I showed is another generic approach without xattr where the new
> > method to whiteout is unnecessary.
> 
> I'm yet to see the reason that would make implementing that method a big
> disadvantage, TBH...

It's the fact that a directory entry based whiteout limits the amount of
change to the VFS, but has to be supported by underlying filesystems.
The generic_dirent_fallthrough() mechanism is a nice way of hiding it,
but there are still quite a few fs specific mods in the union mount tree
because of this.  Having to modify filesystems to me indicates the
mechanism is a bit fragile.  If we could do whiteouts purely in the VFS,
so it would work for any filesystem (without needing filesystem
modifications) that would seem to be a more robust approach.  I'm not
saying we can definitely do this in an elegant way ... I'm just saying
that if someone comes up with it, it's obviously preferable.

James



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Fri, Mar 15, 2013 at 02:09:14PM +0900, J. R. Okajima wrote:

> If so, it has a big disadvantage for the layer-fs (or branch-fs) to have
> to implement a new method for whiteout.
> 
> Overlayfs implements whiteout as symlink+xattr which consumes an
> inode. And you don't like it, right?
> What I showed is another generic approach without xattr where the new
> method to whiteout is unnecessary.

I'm yet to see the reason that would make implementing that method a big
disadvantage, TBH...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Al Viro:
> > +- whiteout is hardlinked in order to reduce the consumption of inodes
> > +  on branch
>
> *blink* Whiteouts have no inodes at all.  Filesystem has an additional
> kind of directory entries, recognizable as whiteouts.  How they are
> done is up to filesystem in question.

"no inodes at all"?
Are you assuming the implementation in dcache only (with a new d_type
flag)? And it is up to the real fs (layer or branch) whether it consumes
inode or not?
If so, it has a big disadvantage for the layer-fs (or branch-fs) to have
to implement a new method for whiteout.

Overlayfs implements whiteout as symlink+xattr which consumes an
inode. And you don't like it, right?
What I showed is another generic approach without xattr where the new
method to whiteout is unnecessary.


> > +The whiteout in aufs is very similar to Unionfs's. That is represented
> > +by its filename. UnionMount takes an approach of a file mode, but I am
> > +afraid several utilities (find(1) or something) will have to support it.
>
> Why the devil should find(1) even see them?

It is the case when find(1) for the layer-fs/branch-fs directly.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Fri, Mar 15, 2013 at 01:15:36PM +0900, J. R. Okajima wrote:

> +- whiteout is hardlinked in order to reduce the consumption of inodes
> +  on branch

*blink* Whiteouts have no inodes at all.  Filesystem has an additional
kind of directory entries, recognizable as whiteouts.  How they are
done is up to filesystem in question.

> +- kernel thread for removing the dir who has a plenty of whiteouts

Again, implementation detail for individual filesystem.

> +The whiteout in aufs is very similar to Unionfs's. That is represented
> +by its filename. UnionMount takes an approach of a file mode, but I am
> +afraid several utilities (find(1) or something) will have to support it.

Why the devil should find(1) even see them?

I really don't believe that it's a good idea to try making them fs-agnostic;
it's an implementation detail of filesystem, with things like "is this
directory empty?" very much belonging to the fs in question...

I don't know; maybe it's my experience of dealing with umsdos that has badly
soured me on that kind of approach, but IME this kind of schemes tend to
be brittle as hell ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Al Viro:
> Umm...  I would prefer it to go through vfs.git, with serious modifications.
> I really don't like the idea of xattr-based whiteouts, for example.

I'd ask you how do you think another whiteout approach?
Here is a part of a posts which describes about aufs2 in 2009


:::
+- whiteout is hardlinked in order to reduce the consumption of inodes
+  on branch
:::
+- kernel thread for removing the dir who has a plenty of whiteouts
:::
+The whiteout is for hiding files on lower branches. Also it is applied
+to stop readdir going lower branches.
+The latter case is called \[oq]opaque directory.\[cq] Any
+whiteout is an empty file, it means whiteout is just an mark.
+In the case of hiding lower files, the name of whiteout is
+\[oq]\*[AUFS_WH_PFX].\[cq]
+And in the case of stopping readdir, the name is
+\[oq]\*[AUFS_WH_PFX]\*[AUFS_WH_PFX].opq\[cq] or
+\[oq]\*[AUFS_WH_PFX]__dir_opaque.\[cq] The name depends upon your compile
+configuration
+CONFIG_AUFS_COMPAT.
+.\" All of newly created or renamed directory will be opaque.
+All whiteouts are hardlinked,
+including \[oq]/\*[AUFS_WH_BASE].\[cq]
:::
+The whiteout in aufs is very similar to Unionfs's. That is represented
+by its filename. UnionMount takes an approach of a file mode, but I am
+afraid several utilities (find(1) or something) will have to support it.
+
+Basically the whiteout represents "logical deletion" which stops aufs to
+lookup further, but also it represents "dir is opaque" which also stop
+lookup.
+
+In aufs, rmdir(2) and rename(2) for dir uses whiteout alternatively.
+In order to make several functions in a single systemcall to be
+revertible, aufs adopts an approach to rename a directory to a temporary
+unique whiteouted name.
+For example, in rename(2) dir where the target dir already existed, aufs
+renames the target dir to a temporary unique whiteouted name before the
+actual rename on a branch and then handles other actions (make it opaque,
+update the attributes, etc). If an error happens in these actions, aufs
+simply renames the whiteouted name back and returns an error. If all are
+succeeded, aufs registers a function to remove the whiteouted unique
+temporary name completely and asynchronously to the system global
+workqueue.
:::

Latest version is aufs3 (for linux-3.x series), there is no essential
changes about whiteout since aufs2.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Thu, Mar 14, 2013 at 02:43:32PM +0100, Miklos Szeredi wrote:

> > Either way, I suggest the next step is to ask Stephen to line this up
> > in linux-next.
> 
> Al, are you okay with that?  Or do you want it to go though -vfs?

Umm...  I would prefer it to go through vfs.git, with serious modifications.
I really don't like the idea of xattr-based whiteouts, for example.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Miklos Szeredi]

On Thu, Mar 14, 2013 at 12:08 AM, Andrew Morton
 wrote:
> On Wed, 13 Mar 2013 15:16:24 +0100 Miklos Szeredi  wrote:
>
>> Here's another version with the comments addressed plus a small bugfix and 
>> some
>> checkpatch cleanups.
>
> It all looks nice to my rusty eye.  But then, I like anything which has
> comments and passes checkpatch ;)
>
> I see that quite a few people have contributed - have you need getting
> enough review and testing feedback?

Well, testing feedback I got plenty when it was all new and full of
bugs. Now I don't get much.  All I usually get nowdays is people
asking why is it not in mainline yet.

> Either way, I suggest the next step is to ask Stephen to line this up
> in linux-next.

Al, are you okay with that?  Or do you want it to go though -vfs?

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Andrew Morton]

On Wed, 13 Mar 2013 15:16:24 +0100 Miklos Szeredi  wrote:

> Here's another version with the comments addressed plus a small bugfix and 
> some
> checkpatch cleanups.

It all looks nice to my rusty eye.  But then, I like anything which has
comments and passes checkpatch ;)

I see that quite a few people have contributed - have you need getting
enough review and testing feedback?

Either way, I suggest the next step is to ask Stephen to line this up
in linux-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Phillip Lougher]

On Wed, Mar 13, 2013 at 4:10 PM, Sedat Dilek  wrote:
> On Wed, Mar 13, 2013 at 4:53 PM, Sedat Dilek  wrote:
>> On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek  wrote:
>>> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi  wrote:
> Looks like this is missing (or intended?):
>
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 482c26f..f23ebfc 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>
>  module_init(ovl_init);
>  module_exit(ovl_exit);
> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem 
> functionality");
> +MODULE_AUTHOR("Miklos Szeredi ");
> +MODULE_LICENSE("GPL");

 No, it *is* already in there.

>>>
>>> Where is it?
>>>
>>> Last lines in [1] are:
>>>
>>> 685 module_init(ovl_init);
>>> 686 module_exit(ovl_exit);
>>>
>>
>> OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.
>>
>> Hehe, with my patch that looks now funny :-).
>>
>> $ sudo modinfo overlayfs
>> filename:
>> /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
>> license:GPL
>> author: Miklos Szeredi 
>> description:overlayfs v17, provides overlay-filesystem functionality
>> alias:  fs-overlayfs
>> license:GPL
>> description:Overlay filesystem
>> author: Miklos Szeredi 
>> srcversion: 4332BB91603829A85CCEA59
>> depends:
>> intree: Y
>> vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload 
>> modversions
>>
>>
>> $ sudo modinfo squashfs
>> filename:
>> /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
>> license:GPL
>> author: Phillip Lougher 
>> description:squashfs 4.0, a compressed read-only filesystem
>> alias:  fs-squashfs
>> srcversion: 752DB671D8E8DFB606BFC88
>> depends:
>> intree: Y
>> vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload 
>> modversions
>>
>
> Nah, SquashFS has MODULE_ALIAS_FS in Linux-Next, but /me looked into 
> Linus-tree.
>
> You are right, you have those MODULE_XXX at the beginning of
> fs/overlayfs/super.c
>
> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
> when the kernel-module is loaded.
> So, is this intended?
> SquashFS prints into the logs, so what is it doing differently?

SquashFS did it because it was out of tree for a long time, and you
couldn't use the kernel version to tell what version of Squashfs you
had patched in.

When people dug about in their embedded system (router, STB etc.) they
often got kernels without modules, without source and no idea of the
Squashfs version...   When they emailed me to ask why xyz Squashfs
filesystem wouldn't mount, which version of squashfs-tools they should
use, I often had no way of knowing.

Phillip

(re-sending to mailing lists because the original got bounced - I
thought I'd told gmail never to send HTML)

>
> - Sedat -
>
>
>> - Sedat -
>>
>>> - Sedat -
>>>
>>> [1] 
>>> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>>>
 Thanks,
 Miklos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 9:13 PM, Phillip Lougher
 wrote:
>
>
> On Wed, Mar 13, 2013 at 4:10 PM, Sedat Dilek  wrote:
>>
>> On Wed, Mar 13, 2013 at 4:53 PM, Sedat Dilek 
>> wrote:
>> > On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek 
>> > wrote:
>> >> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi 
>> >> wrote:
>>  Looks like this is missing (or intended?):
>> 
>>  diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>  index 482c26f..f23ebfc 100644
>>  --- a/fs/overlayfs/super.c
>>  +++ b/fs/overlayfs/super.c
>>  @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>> 
>>   module_init(ovl_init);
>>   module_exit(ovl_exit);
>>  +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem
>>  functionality");
>>  +MODULE_AUTHOR("Miklos Szeredi ");
>>  +MODULE_LICENSE("GPL");
>> >>>
>> >>> No, it *is* already in there.
>> >>>
>> >>
>> >> Where is it?
>> >>
>> >> Last lines in [1] are:
>> >>
>> >> 685 module_init(ovl_init);
>> >> 686 module_exit(ovl_exit);
>> >>
>> >
>> > OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.
>> >
>> > Hehe, with my patch that looks now funny :-).
>> >
>> > $ sudo modinfo overlayfs
>> > filename:
>> >
>> > /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
>> > license:GPL
>> > author: Miklos Szeredi 
>> > description:overlayfs v17, provides overlay-filesystem functionality
>> > alias:  fs-overlayfs
>> > license:GPL
>> > description:Overlay filesystem
>> > author: Miklos Szeredi 
>> > srcversion: 4332BB91603829A85CCEA59
>> > depends:
>> > intree: Y
>> > vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload
>> > modversions
>> >
>> >
>> > $ sudo modinfo squashfs
>> > filename:
>> >
>> > /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
>> > license:GPL
>> > author: Phillip Lougher 
>> > description:squashfs 4.0, a compressed read-only filesystem
>> > alias:  fs-squashfs
>> > srcversion: 752DB671D8E8DFB606BFC88
>> > depends:
>> > intree: Y
>> > vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload
>> > modversions
>> >
>>
>> Nah, SquashFS has MODULE_ALIAS_FS in Linux-Next, but /me looked into
>> Linus-tree.
>>
>> You are right, you have those MODULE_XXX at the beginning of
>> fs/overlayfs/super.c
>>
>> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>> when the kernel-module is loaded.
>> So, is this intended?
>> SquashFS prints into the logs, so what is it doing differently?
>
>
> SquashFS did it because it was out of tree for a long time, and you couldn't
> use the kernel version to tell what version of Squashfs you had patched in.
>
> When people dug about in their embedded system (router, STB etc.) they often
> got kernels without modules, without source and no idea of the Squashfs
> version...   When they emailed me to ask why xyz Squashfs filesystem
> wouldn't mount, which version of squashfs-tools they should use, I often had
> no way of knowing.
>

Hi Phillip,

thanks for your explanations.

I can imagine that sometimes to have version and date is helpful for
the developer.
But /me thinks the way it was implemented is not very cool.
See "version.h" in fs/btrfs and appropriate printk-line in fs/btrfs/super.c.
That solution pleased me well.
There you can put all the relevant informations (even you insist to
display your $author :-)).

But as said in another email that status information stuff is not
handled unique/consequently in fs/.
I just fell over it... not more not less. Asking should be allowed.

- Sedat -


> Phillip
>
>>
>> - Sedat -
>>
>>
>> > - Sedat -
>> >
>> >> - Sedat -
>> >>
>> >> [1]
>> >> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>> >>
>> >>> Thanks,
>> >>> Miklos
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
>> in
>>
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 8:58 PM, Linus Torvalds
 wrote:
> On Wed, Mar 13, 2013 at 12:54 PM, Eric W. Biederman
>  wrote:
>>>
>>> Hehe, I just checked my new kernel... that does not work (nothing in the 
>>> logs).
>>> But I think it's good to see if the filesystem is registered/loaded.
>>
>> lsmod | grep overlayfs
>
> How about the compiled-in case? What's wrong with just using the
> obvious /proc/filesystems?
>

As I don't need OverlayFS in my daily life, I have it here built as a module.

Nevertheless, as module or built-in /me as an end-user wants to know
what's going on.
So, dmesg is normally my first weapon.

I grep-ed trrough a bit through all the filesystems in fs/ and it is
not handled unique.

"Loaded" BTW is not the right term in FS-folks-jargon: The functions
are called (un)register_filesystem().

$ dmesg | grep -i loaded
[0.241037] vgaarb: loaded
[0.241243] libata version 3.00 loaded.
[0.358574] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[0.368711] brd: module loaded
[0.369832] loop: module loaded
[0.650086] PM: Hibernation image not present or could not be loaded.
[0.651150] Loaded X.509 cert 'Magrathea: Glacier signing key:
e75e3a59e59cb48db975ac12e21a905289ada56f'
[1.788947] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[8.617549] lp: driver loaded but no devices found
[   10.490721] wmi: Mapper loaded
[   11.994985] iwlwifi :01:00.0: loaded firmware version 18.168.6.1
[   73.885056] squashfs: loaded
[   81.345070] overlayfs: loaded

I am not sure whether those lines "blabla: module loaded" is true for
loop (block) it is a hardcoded printk-line.
I doubt...

CONFIG_BLK_DEV_LOOP=y

Last but not least, user-space apps like GRUB trigger fs loaded.
For me this is helpful.
You might be bored or whatever reason I can't or don't want to understand.

And just to have some fun about status informations:
Check your drm (kms) driver with date and version :-).
Stuff that is not maintained should be thrown out (yes, I had sent patches...).

- Sedat -

>  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Linus Torvalds]

On Wed, Mar 13, 2013 at 12:54 PM, Eric W. Biederman
 wrote:
>>
>> Hehe, I just checked my new kernel... that does not work (nothing in the 
>> logs).
>> But I think it's good to see if the filesystem is registered/loaded.
>
> lsmod | grep overlayfs

How about the compiled-in case? What's wrong with just using the
obvious /proc/filesystems?

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Eric W. Biederman]

Sedat Dilek  writes:

> On Wed, Mar 13, 2013 at 7:37 PM, Felix Fietkau  wrote:
>> On 2013-03-13 7:12 PM, Robin Holt wrote:
>>> On Wed, Mar 13, 2013 at 05:51:33PM +0100, Sedat Dilek wrote:
 On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi  wrote:
 > On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  
 > wrote:
 >
 >> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
 >> when the kernel-module is loaded.
 >> So, is this intended?
 >> SquashFS prints into the logs, so what is it doing differently?
 >
 > Some modules do, some don't.  It's not compulsory and not very useful.
 >

 What about...

 diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
 index 482c26f..92b9ad5 100644
 --- a/fs/overlayfs/super.c
 +++ b/fs/overlayfs/super.c
 @@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
  static int __init ovl_init(void)
  {
 return register_filesystem(&ovl_fs_type);
 +   printk(KERN_INFO "overlayfs: loaded\n");
>>>
>>> How about pr_debug().  That makes things quite for most of us but gives
>>> you info when looking for things like boot problems.
>> How is having a printk/pr_debug useful here at all? The fact that other
>> filesystems do this as well is not a good reason...
>> Also, putting it *after* the return statement doesn't make much sense ;)
>>
>
> Hehe, I just checked my new kernel... that does not work (nothing in the 
> logs).
> But I think it's good to see if the filesystem is registered/loaded.

lsmod | grep overlayfs

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 7:37 PM, Felix Fietkau  wrote:
> On 2013-03-13 7:12 PM, Robin Holt wrote:
>> On Wed, Mar 13, 2013 at 05:51:33PM +0100, Sedat Dilek wrote:
>>> On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi  wrote:
>>> > On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  
>>> > wrote:
>>> >
>>> >> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>>> >> when the kernel-module is loaded.
>>> >> So, is this intended?
>>> >> SquashFS prints into the logs, so what is it doing differently?
>>> >
>>> > Some modules do, some don't.  It's not compulsory and not very useful.
>>> >
>>>
>>> What about...
>>>
>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>> index 482c26f..92b9ad5 100644
>>> --- a/fs/overlayfs/super.c
>>> +++ b/fs/overlayfs/super.c
>>> @@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
>>>  static int __init ovl_init(void)
>>>  {
>>> return register_filesystem(&ovl_fs_type);
>>> +   printk(KERN_INFO "overlayfs: loaded\n");
>>
>> How about pr_debug().  That makes things quite for most of us but gives
>> you info when looking for things like boot problems.
> How is having a printk/pr_debug useful here at all? The fact that other
> filesystems do this as well is not a good reason...
> Also, putting it *after* the return statement doesn't make much sense ;)
>

Hehe, I just checked my new kernel... that does not work (nothing in the logs).
But I think it's good to see if the filesystem is registered/loaded.

- Sedat -

> - Felix
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Felix Fietkau]

On 2013-03-13 7:12 PM, Robin Holt wrote:
> On Wed, Mar 13, 2013 at 05:51:33PM +0100, Sedat Dilek wrote:
>> On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi  wrote:
>> > On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  wrote:
>> >
>> >> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>> >> when the kernel-module is loaded.
>> >> So, is this intended?
>> >> SquashFS prints into the logs, so what is it doing differently?
>> >
>> > Some modules do, some don't.  It's not compulsory and not very useful.
>> >
>> 
>> What about...
>> 
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 482c26f..92b9ad5 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
>>  static int __init ovl_init(void)
>>  {
>> return register_filesystem(&ovl_fs_type);
>> +   printk(KERN_INFO "overlayfs: loaded\n");
> 
> How about pr_debug().  That makes things quite for most of us but gives
> you info when looking for things like boot problems.
How is having a printk/pr_debug useful here at all? The fact that other
filesystems do this as well is not a good reason...
Also, putting it *after* the return statement doesn't make much sense ;)

- Felix

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Robin Holt]

On Wed, Mar 13, 2013 at 05:51:33PM +0100, Sedat Dilek wrote:
> On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi  wrote:
> > On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  wrote:
> >
> >> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
> >> when the kernel-module is loaded.
> >> So, is this intended?
> >> SquashFS prints into the logs, so what is it doing differently?
> >
> > Some modules do, some don't.  It's not compulsory and not very useful.
> >
> 
> What about...
> 
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 482c26f..92b9ad5 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
>  static int __init ovl_init(void)
>  {
> return register_filesystem(&ovl_fs_type);
> +   printk(KERN_INFO "overlayfs: loaded\n");

How about pr_debug().  That makes things quite for most of us but gives
you info when looking for things like boot problems.

>  }
> 
>  static void __exit ovl_exit(void)
>  {
> unregister_filesystem(&ovl_fs_type);
> +   printk(KERN_INFO "overlayfs: unloaded\n");
>  }
> 
>  module_init(ovl_init);
> 
> Maybe "loaded" is enough.
> 
> - Sedat -
> 
> > Thanks,
> > Miklos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi  wrote:
> On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  wrote:
>
>> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>> when the kernel-module is loaded.
>> So, is this intended?
>> SquashFS prints into the logs, so what is it doing differently?
>
> Some modules do, some don't.  It's not compulsory and not very useful.
>

What about...

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 482c26f..92b9ad5 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -675,11 +675,13 @@ MODULE_ALIAS_FS("overlayfs");
 static int __init ovl_init(void)
 {
return register_filesystem(&ovl_fs_type);
+   printk(KERN_INFO "overlayfs: loaded\n");
 }

 static void __exit ovl_exit(void)
 {
unregister_filesystem(&ovl_fs_type);
+   printk(KERN_INFO "overlayfs: unloaded\n");
 }

 module_init(ovl_init);

Maybe "loaded" is enough.

- Sedat -

> Thanks,
> Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 5:21 PM, Miklos Szeredi  wrote:
> On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  wrote:
>
>> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
>> when the kernel-module is loaded.
>> So, is this intended?
>> SquashFS prints into the logs, so what is it doing differently?
>
> Some modules do, some don't.  It's not compulsory and not very useful.
>

That's some hardcoded printk-stuff which is IMHO wrong implemented and outdated.
I hoped that this is handled in al FS-modules the same way.
Do not assume...

- Sedat -

[1] http://marc.info/?l=linux-kernel&m=136319193916686&w=2

> Thanks,
> Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Miklos Szeredi]

On Wed, Mar 13, 2013 at 5:10 PM, Sedat Dilek  wrote:

> Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
> when the kernel-module is loaded.
> So, is this intended?
> SquashFS prints into the logs, so what is it doing differently?

Some modules do, some don't.  It's not compulsory and not very useful.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 4:53 PM, Sedat Dilek  wrote:
> On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek  wrote:
>> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi  wrote:
 Looks like this is missing (or intended?):

 diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
 index 482c26f..f23ebfc 100644
 --- a/fs/overlayfs/super.c
 +++ b/fs/overlayfs/super.c
 @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)

  module_init(ovl_init);
  module_exit(ovl_exit);
 +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem 
 functionality");
 +MODULE_AUTHOR("Miklos Szeredi ");
 +MODULE_LICENSE("GPL");
>>>
>>> No, it *is* already in there.
>>>
>>
>> Where is it?
>>
>> Last lines in [1] are:
>>
>> 685 module_init(ovl_init);
>> 686 module_exit(ovl_exit);
>>
>
> OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.
>
> Hehe, with my patch that looks now funny :-).
>
> $ sudo modinfo overlayfs
> filename:
> /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
> license:GPL
> author: Miklos Szeredi 
> description:overlayfs v17, provides overlay-filesystem functionality
> alias:  fs-overlayfs
> license:GPL
> description:Overlay filesystem
> author: Miklos Szeredi 
> srcversion: 4332BB91603829A85CCEA59
> depends:
> intree: Y
> vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload 
> modversions
>
>
> $ sudo modinfo squashfs
> filename:
> /lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
> license:GPL
> author: Phillip Lougher 
> description:squashfs 4.0, a compressed read-only filesystem
> alias:  fs-squashfs
> srcversion: 752DB671D8E8DFB606BFC88
> depends:
> intree: Y
> vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload 
> modversions
>

Nah, SquashFS has MODULE_ALIAS_FS in Linux-Next, but /me looked into Linus-tree.

You are right, you have those MODULE_XXX at the beginning of
fs/overlayfs/super.c

Anyway, with CONFIG_OVERLAYFS_FS=m I do not see any related messages
when the kernel-module is loaded.
So, is this intended?
SquashFS prints into the logs, so what is it doing differently?

- Sedat -


> - Sedat -
>
>> - Sedat -
>>
>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>>
>>> Thanks,
>>> Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 4:26 PM, Sedat Dilek  wrote:
> On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi  wrote:
>>> Looks like this is missing (or intended?):
>>>
>>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>>> index 482c26f..f23ebfc 100644
>>> --- a/fs/overlayfs/super.c
>>> +++ b/fs/overlayfs/super.c
>>> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>>>
>>>  module_init(ovl_init);
>>>  module_exit(ovl_exit);
>>> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem 
>>> functionality");
>>> +MODULE_AUTHOR("Miklos Szeredi ");
>>> +MODULE_LICENSE("GPL");
>>
>> No, it *is* already in there.
>>
>
> Where is it?
>
> Last lines in [1] are:
>
> 685 module_init(ovl_init);
> 686 module_exit(ovl_exit);
>

OK, I looked at SquashFS which is not converted to use MODULE_ALIAS_FS.

Hehe, with my patch that looks now funny :-).

$ sudo modinfo overlayfs
filename:
/lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/overlayfs/overlayfs.ko
license:GPL
author: Miklos Szeredi 
description:overlayfs v17, provides overlay-filesystem functionality
alias:  fs-overlayfs
license:GPL
description:Overlay filesystem
author: Miklos Szeredi 
srcversion: 4332BB91603829A85CCEA59
depends:
intree: Y
vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload modversions


$ sudo modinfo squashfs
filename:
/lib/modules/3.9.0-rc2-next20130313-4-iniza-small/kernel/fs/squashfs/squashfs.ko
license:GPL
author: Phillip Lougher 
description:squashfs 4.0, a compressed read-only filesystem
alias:  fs-squashfs
srcversion: 752DB671D8E8DFB606BFC88
depends:
intree: Y
vermagic:   3.9.0-rc2-next20130313-4-iniza-small SMP mod_unload modversions

- Sedat -

> - Sedat -
>
> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current
>
>> Thanks,
>> Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 4:18 PM, Miklos Szeredi  wrote:
>> Looks like this is missing (or intended?):
>>
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 482c26f..f23ebfc 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>>
>>  module_init(ovl_init);
>>  module_exit(ovl_exit);
>> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem 
>> functionality");
>> +MODULE_AUTHOR("Miklos Szeredi ");
>> +MODULE_LICENSE("GPL");
>
> No, it *is* already in there.
>

Where is it?

Last lines in [1] are:

685 module_init(ovl_init);
686 module_exit(ovl_exit);

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/fs/overlayfs/super.c?h=overlayfs.current

> Thanks,
> Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Miklos Szeredi]

> Looks like this is missing (or intended?):
>
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 482c26f..f23ebfc 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -684,3 +684,6 @@ static void __exit ovl_exit(void)
>
>  module_init(ovl_init);
>  module_exit(ovl_exit);
> +MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem 
> functionality");
> +MODULE_AUTHOR("Miklos Szeredi ");
> +MODULE_LICENSE("GPL");

No, it *is* already in there.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Sedat Dilek]

On Wed, Mar 13, 2013 at 3:31 PM, Sedat Dilek  wrote:
> On Wed, Mar 13, 2013 at 3:16 PM, Miklos Szeredi  wrote:
>> Here's another version with the comments addressed plus a small bugfix and 
>> some
>> checkpatch cleanups.
>>
>> Changes in v17:
>>
>>  - fix wrong return value in a failure path in ovl_link()
>>  - fix subjects
>>  - use file_inode() and MODULE_ALIAS_FS()
>>  - fold bugfix patches
>>  - checkpatch cleanups
>>
>> Git tree is here:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
>> overlayfs.current
>>
>
> Hi,
>
> I pulled in v17 (current) into Linux-Next (next-20130313) and built
> OverlayFS as a module.
>
> Unfortunately, I do not see any success message on loading it.
>
> --- dmesg_3.9.0-rc2-next20130313-3-iniza-small.txt  2013-03-13
> 15:21:19.578712536 +0100
> +++ dmesg_3.9.0-rc2-next20130313-3-iniza-small_after-overlayfs-test.txt
> 2013-03-13 15:22:14.658238998 +0100
> @@ -806,3 +806,8 @@
>  [   25.517154] wlan0: associated
>  [   25.517214] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>  [   54.149536] usb 2-1.5: USB disconnect, device number 3
> +[   86.502215] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> +[   87.007082] EXT4-fs (loop4): mounted filesystem with ordered data
> mode. Opts: (null)
> +[   87.311998] EXT4-fs (loop4): re-mounted. Opts: data=ordered
> +[   87.657291] EXT4-fs (loop4): re-mounted. Opts: data=ordered
> +[   88.057251] EXT4-fs (loop4): re-mounted. Opts: data=ordered
>
> Highly appreciated to see such a message!
>
> Test-case script attached (needs an additional patch on top of
> overlayfs.current, see attachments).
>

Looks like this is missing (or intended?):

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 482c26f..f23ebfc 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -684,3 +684,6 @@ static void __exit ovl_exit(void)

 module_init(ovl_init);
 module_exit(ovl_exit);
+MODULE_DESCRIPTION("overlayfs v17: provides overlay-filesystem functionality");
+MODULE_AUTHOR("Miklos Szeredi ");
+MODULE_LICENSE("GPL");

Feel free to correct if I fill in bullshit...

- Sedat -

> - Sedat -
>
>> Thanks,
>> Miklos
>>
>> ---
>> Andy Whitcroft (1):
>>   overlayfs: add statfs support
>>
>> Erez Zadok (1):
>>   overlayfs: implement show_options
>>
>> Miklos Szeredi (6):
>>   vfs: add i_op->dentry_open()
>>   vfs: export do_splice_direct() to modules
>>   vfs: export __inode_permission() to modules
>>   vfs: introduce clone_private_mount()
>>   overlay filesystem
>>   fs: limit filesystem stacking depth
>>
>> Neil Brown (1):
>>   overlay: overlay filesystem documentation
>>
>> ---
>>  Documentation/filesystems/Locking   |2 +
>>  Documentation/filesystems/overlayfs.txt |  199 +
>>  Documentation/filesystems/vfs.txt   |7 +
>>  MAINTAINERS |7 +
>>  fs/Kconfig  |1 +
>>  fs/Makefile |1 +
>>  fs/ecryptfs/main.c  |7 +
>>  fs/internal.h   |5 -
>>  fs/namei.c  |   10 +-
>>  fs/namespace.c  |   18 +
>>  fs/open.c   |   23 +-
>>  fs/overlayfs/Kconfig|   10 +
>>  fs/overlayfs/Makefile   |7 +
>>  fs/overlayfs/copy_up.c  |  385 +
>>  fs/overlayfs/dir.c  |  605 +++
>>  fs/overlayfs/inode.c|  372 +
>>  fs/overlayfs/overlayfs.h|   70 
>>  fs/overlayfs/readdir.c  |  566 +
>>  fs/overlayfs/super.c|  686 
>> +++
>>  fs/splice.c |1 +
>>  include/linux/fs.h  |   14 +
>>  include/linux/mount.h   |3 +
>>  22 files changed, 2989 insertions(+), 10 deletions(-)
>>  create mode 100644 Documentation/filesystems/overlayfs.txt
>>  create mode 100644 fs/overlayfs/Kconfig
>>  create mode 100644 fs/overlayfs/Makefile
>>  create mode 100644 fs/overlayfs/copy_up.c
>>  create mode 100644 fs/overlayfs/dir.c
>>  create mode 100644 fs/overlayfs/inode.c
>>  create mode 100644 fs/overlayfs/overlayfs.h
>>  create mode 100644 fs/overlayfs/readdir.c
>>  create mode 100644 fs/overlayfs/super.c
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/