Re: unification filesystems -- packaging aufs2, etc.

2009-07-07 Thread Julian Andres Klode
On Mon, Jul 6, 2009 at 6:10 PM, Daniel Baumanndan...@debian.org wrote:
 in the meanwhile, having not looked at the issues myself at all, is it
 reasonably possible to patch aufs1 for 2.6.30?
I have already compiled it against 2.6.30 using the current version in unstable,
but I have not tested the module yet. It should work.

-- 
Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juli...@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: unification filesystems -- packaging aufs2, etc.

2009-07-07 Thread Julian Andres Klode
On Mon, Jul 06, 2009 at 06:10:32PM +0200, Daniel Baumann wrote:
 Julian Andres Klode wrote:
  Proposal
  -
  It seems to be the best idea to use unionfs-fuse for now (like Ubuntu)
  until a new kernel-based solution has been packaged. It may also be a
  good idea to coordinate this with the Ubuntu developers, so both distros
  can use the same method of filesystem unification.
  
  1. The Debian Live project adds support for unionfs-fuse.
 
 this shouldn't be that hard, however, it's a serious regression in terms
 of speed, therefore i really hope kernel team will accepts aufs2 patches.

Another option for Debian Live would be to use Device Mapper, like Fedora
does, by using an ext3 image which is located inside a SquashFS image. This
way, you only need functionality already provided by the kernel and no
external modules.

But even if this is a realistic option, we still need filesystems such as
unionfs or aufs for other users. And hacking the filesystem to work without
kernel patches is possible, but it leads to security problems and probably
other problems as well.
-- 
Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juli...@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/


signature.asc
Description: Digital signature


unification filesystems -- packaging aufs2, etc.

2009-07-06 Thread Julian Andres Klode
Hi everyone,

I would like to remove aufs from Debian soon, as it is not maintained
upstream anymore. But before this can happen, we have to find an
alternative which provides a reasonable feature set and comparable
performance.

This email is sent to the debian-kernel team for advice on the
kernel-based solutions and to the debian-live team as the most
important user. I also CCed the maintainers of the userspace
filesystems.

Why remove aufs1?
-
The last update to aufs1 is from January 2009. It has since been
replaced by aufs2. I don't want to maintain a whole filesystem
without any kind of upstream.

Alternatives: Kernelspace filesystems
-
There are two candidates: Unionfs2 and Aufs2. The problem with both
filesystems is that they require patches to the kernel, whereas aufs2
seems to be safer as it requires only new exports to be added.

There is also a new technology called union-mount, but I don't know
how mature this solution is.

None of these filesystems are packaged yet. If we were to decide for
kernel-based unification, one of those has to be packaged and the
kernel team has to accept patches to make this work.

I have attached the kernel patches needed for each filesystem, so
they can be reviewed. The Unionfs patch can be reduced to export
do_splice_{from,to} (without renaming to vfs_splice_{from,to}),
exporting security_inode_permission and the change to
fsstack_copy_inode_size(). The aufs patch is larger, but has the
benefit of only adding new exports without changing existing
functions.


Alternatives: Userspace filesystems
---
There are also userspace alternatives. Debian currently provides
unionfs-fuse, packaged by Bernd Schubert bernd.schub...@fastmail.fm.

Another alternative seems to be mhddfs, packaged by 
Dmitry E. Oboukhov un...@debian.org. 

Proposal
-
It seems to be the best idea to use unionfs-fuse for now (like Ubuntu)
until a new kernel-based solution has been packaged. It may also be a
good idea to coordinate this with the Ubuntu developers, so both distros
can use the same method of filesystem unification.

1. The Debian Live project adds support for unionfs-fuse.
2. A new filesystem will be packaged (unionfs2 OR aufs2).
3. aufs will be removed from unstable (or be replaced by
   aufs2 under the same name).

Regards,
Julian Andres Klode

(Please always CC me on replies, I'm not subscribed to any of the
mailing lists this mail is sent to.)
-- 
Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juli...@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/
aufs2 standalone patch for linux-2.6.30

diff --git a/fs/namei.c b/fs/namei.c
index 967c3db..64a5060 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -337,6 +337,7 @@ int deny_write_access(struct file * file)
 
 	return 0;
 }
+EXPORT_SYMBOL(deny_write_access);
 
 /**
  * path_get - get a reference to a path
@@ -1200,7 +1201,7 @@ out:
  * needs parent already locked. Doesn't follow mounts.
  * SMP-safe.
  */
-static struct dentry *lookup_hash(struct nameidata *nd)
+struct dentry *lookup_hash(struct nameidata *nd)
 {
 	int err;
 
@@ -1209,8 +1210,9 @@ static struct dentry *lookup_hash(struct nameidata *nd)
 		return ERR_PTR(err);
 	return __lookup_hash(nd-last, nd-path.dentry, nd);
 }
+EXPORT_SYMBOL(lookup_hash);
 
-static int __lookup_one_len(const char *name, struct qstr *this,
+int __lookup_one_len(const char *name, struct qstr *this,
 		struct dentry *base, int len)
 {
 	unsigned long hash;
@@ -1231,6 +1233,7 @@ static int __lookup_one_len(const char *name, struct qstr *this,
 	this-hash = end_name_hash(hash);
 	return 0;
 }
+EXPORT_SYMBOL(__lookup_one_len);
 
 /**
  * lookup_one_len - filesystem helper to lookup single pathname component
diff --git a/fs/namespace.c b/fs/namespace.c
index 134d494..5a6d038 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -38,6 +38,7 @@
 
 /* spinlock for vfsmount related operations, inplace of dcache_lock */
 __cacheline_aligned_in_smp DEFINE_SPINLOCK(vfsmount_lock);
+EXPORT_SYMBOL(vfsmount_lock);
 
 static int event;
 static DEFINE_IDA(mnt_id_ida);
diff --git a/fs/open.c b/fs/open.c
index bdfbf03..81c39b3 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -221,6 +221,7 @@ int do_truncate(struct dentry *dentry, loff_t length, unsigned int time_attrs,
 	mutex_unlock(dentry-d_inode-i_mutex);
 	return err;
 }
+EXPORT_SYMBOL(do_truncate);
 
 static long do_sys_truncate(const char __user *pathname, loff_t length)
 {
diff --git a/fs/splice.c b/fs/splice.c
index 666953d..fbc3f77 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -905,8 +905,8 @@ EXPORT_SYMBOL(generic_splice_sendpage);
 /*
  * Attempt to initiate a splice from pipe to file.
  */
-static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
-			   

Re: unification filesystems -- packaging aufs2, etc.

2009-07-06 Thread Bernd Schubert
Hello Julian,

On Monday 06 July 2009, Julian Andres Klode wrote:
 -
 It seems to be the best idea to use unionfs-fuse for now (like Ubuntu)
 until a new kernel-based solution has been packaged. It may also be a
 good idea to coordinate this with the Ubuntu developers, so both distros
 can use the same method of filesystem unification.

 1. The Debian Live project adds support for unionfs-fuse.
 2. A new filesystem will be packaged (unionfs2 OR aufs2).
 3. aufs will be removed from unstable (or be replaced by
aufs2 under the same name).

I also would like to get involved into the Debian Live project then, as I 
guess I know how to workaround issues. For example one of the problems with 
fuse filesystems is that killall5 will terminate it during the shutdown 
process. Fortunately Debian has as workaround in sysvinit-utils and the 
unionfs-fuse package also provides an example rc.local script.


Thanks,
Bernd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: unification filesystems -- packaging aufs2, etc.

2009-07-06 Thread Daniel Baumann
Julian Andres Klode wrote:
 Proposal
 -
 It seems to be the best idea to use unionfs-fuse for now (like Ubuntu)
 until a new kernel-based solution has been packaged. It may also be a
 good idea to coordinate this with the Ubuntu developers, so both distros
 can use the same method of filesystem unification.
 
 1. The Debian Live project adds support for unionfs-fuse.

this shouldn't be that hard, however, it's a serious regression in terms
of speed, therefore i really hope kernel team will accepts aufs2 patches.

 2. A new filesystem will be packaged (unionfs2 OR aufs2).
 3. aufs will be removed from unstable (or be replaced by
aufs2 under the same name).

in the meanwhile, having not looked at the issues myself at all, is it
reasonably possible to patch aufs1 for 2.6.30?

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: unification filesystems -- packaging aufs2, etc.

2009-07-06 Thread Daniel Baumann
Bernd Schubert wrote:
 I also would like to get involved into the Debian Live project then

very easy and welcome.. please clone
git://git.debian.net/git/debian-live/live-initramfs.git and send patches.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org