Re: Subject: [PATCH 00/16] Squashfs: compressedread-only filesystem
From: David P. Quigley
Date: Tue Oct 21 2008 - 12:29:37 EST
On Tue, 2008-10-21 at 02:12 +0100, Phillip Lougher wrote:
> David P. Quigley wrote:
> > Looking through the code I see two references to xattrs, one is the
> > index of the xattr table in the superblock and there seems to be struct
> > member in one of the inode structures that is an index into this table.
> > Looking through the code I don't see either of these used at all. Do you
> > intend to add xattr support at some point? I saw reference to the desire
> > to add xattr support in an email from 2004 but you said that the code
> > has been rewritten since then. If you are going to add xattr support you
> > probably want to add it to more than just regular files. In SELinux and
> > other LSMs symlinks and directories are also labeled so they will need
> > xattr entries.
> Yes and yes. I am intending to add xattr support, something that's been
> on my to-do list for a long time (since 2004 as you said), but it's been
> something which I've never got the time to do. Once (if) Squashfs is
> mainlined, it will be the next thing.
> The xattr references in the layout is my attempt at forward planning to
> avoid making an incompatible layout change when I finally get around to
> implementing it. My plan is to put xattrs in a table (referenced by the
> superblock), and then put indexes in "extended" inodes which index
> into the table (as you noticed). The general idea in Squashfs is that
> inodes get optimised for normally occurring cases, and less common cases
> (that would need a bigger inode) get to use an extended inode.
> Squashfs currently has an extended regular file inode, which is where
> the xattr index will sit, and so this has had an xattr index added. The
> other inodes don't currently have extended inodes, these will be defined
> when I implement xattrs (which is why they're missing).
> Having said that, I've fscked up and forgotten to add an xattr field to
> the extended directory inode which is currently defined :)
> Thanks for spotting this.
> > Dave
Looking through the code I noticed that you give certain object types
the same inode number for all instances of it (devices, fifo/sockets).
How is this done internally? Do these types of objects occupy the same
position on the inode table? If so how do you differentiate between a
device and a socket?
I have some other comments but I'll post them under the specific
I use to work on Unionfs and we used CVS initially for our SCM. When we
started working on mainlining Unionfs we moved over to a GIT based
system and we found it worked a lot better. You might want to consider
moving your patches to a GIT tree that you make publically available so
people can just clone, compile, and test them. I don't see anything that
stops Squashfs from being compiled and loaded as a module so it might
not be necessary but it makes it easier for people who want to test the
code or even contribute patches.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/