lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 15 Dec 2006 13:47:10 -0500 (EST)
From:	Nikolai Joukov <kolya@...sunysb.edu>
To:	Al Boldi <a1426z@...ab.com>
cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-raid@...r.kernel.org
Subject: Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems

> Nikolai Joukov wrote:
> > > > We started the project in April 2004.  Right now I am using it as my
> > > > /home/kolya file system at home.  We believe that at this stage RAIF
> > > > is mature enough for others to try it out.  The code is available at:
> > > >
> > > > 	<ftp://ftp.fsl.cs.sunysb.edu/pub/raif/>
> > > >
> > > > The code requires no kernel patches and compiles for a wide range of
> > > > kernels as a module.  The latest kernel we used it for is 2.6.13 and
> > > > we are in the process of porting it to 2.6.19.
> > > >
> > > > We will be happy to hear your back.
> > >
> > > When removing a file from the underlying branch, the oops below happens.
> > > Wouldn't it be possible to just fail the branch instead of oopsing?
> >
> > This is a known problem of all Linux stackable file systems.  Users are
> > not supposed to change the file systems below mounted stackable file
> > systems (but they can read them).  One of the ways to enforce it is to use
> > overlay mounts.  For example, mount the lower file systems at
> > /raif/b0 ... /raif/bN and then mount RAIF at /raif.  Stackable file
> > systems recently started getting into the kernel and we hope that there
> > will be a better solution for this problem in the future.  Having said
> > that, you are right: failing the branch would be the right thing to do.
>
> Good.  It seems that there is also some tmpfs/raif-over-nfs deadlock
> situation.  Can't really tell if it's the kernel or the raif, but when do
> you think the patches could be brought into sync with the current mainline?

It would be great if you could send us more details about how to recreate
this deadlock and we will take a look at it.  It would be even better if
you and everybody else who finds bugs in RAIF submit the bug reports to:

  <http://bugzilla.fsl.cs.sunysb.edu>

We are in the process of porting RAIF to 2.6.19 right now.  Should be done
in early January.  The trick is that we are trying to keep the same source
good for a wide range of kernel versions.  In fact, not too long ago we
even were able to compile it for 2.4.24!

Nikolai.
---------------------
Nikolai Joukov, Ph.D.
Filesystems and Storage Laboratory
Stony Brook University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ