On Mon, Jan 08, 2007 at 06:25:16PM -0500, Josef Sipek wrote:
> > There's no such problem with bind mounts. It's surprising to see such a
> > restriction with union mounts.
>
> Bind mounts are a purely VFS level construct. Unionfs is, as the name
> implies, a filesystem. Last year at OLS, it seeme
On Mon, Jan 08, 2007 at 07:03:35PM -0500, Erez Zadok wrote:
> However, I must caution that a file system like ecryptfs is very different
> from Unionfs, the latter being a fan-out file system---and both have very
> different goals. The common code between the two file systems, at this
> stage, is
On Tue, Jan 09, 2007 at 09:49:35AM +, Christoph Hellwig wrote:
> On Mon, Jan 08, 2007 at 06:25:16PM -0500, Josef Sipek wrote:
> > > There's no such problem with bind mounts. It's surprising to see such a
> > > restriction with union mounts.
> >
> > Bind mounts are a purely VFS level construct
On Tue, Jan 09, 2007 at 09:53:45AM +, Christoph Hellwig wrote:
> On Mon, Jan 08, 2007 at 07:03:35PM -0500, Erez Zadok wrote:
> > However, I must caution that a file system like ecryptfs is very different
> > from Unionfs, the latter being a fan-out file system---and both have very
> > different
On Tue, Jan 09, 2007 at 05:43:33AM -0500, Josef Sipek wrote:
> RAIF is another fan-out stackable fs with much more complex logic. (Just the
> other day, I saw an announcement for a new version on fsdevel.)
I didn't say none exist, but rather none is useful. While RAIF is
definitly an excellent e
On Tue, Jan 09, 2007 at 05:43:33AM -0500, Josef Sipek wrote:
> > I think that's an very important point. We have a chance to get that
> > non-fanout filesystems right quite easily - something I wished that would
> > have been done before the ecryptfs merge - while getting fan-out stackable
> > fil
On Tue, Jan 09, 2007 at 10:57:45AM +1100, David Chinner wrote:
> On Mon, Jan 08, 2007 at 10:54:02PM +, Christoph Hellwig wrote:
> > this doesn't look like a full first class flag to me yet. Don't
> > we need to check for buffer_unwritten in the places we're checking
> > for buffer_delay so we
> In message <[EMAIL PROTECTED]>, Andrew Morton writes:
> > On Sun, 7 Jan 2007 23:12:53 -0500
> > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> >
> > > +Modifying a Unionfs branch directly, while the union is mounted, is
> > > +currently unsupported.
> >
> > Does this mean that if I have /a/
> On Mon, Jan 08, 2007 at 11:18:52AM -0800, Andrew Morton wrote:
> > On Sun, 7 Jan 2007 23:12:53 -0500
> > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> >
> > > Any such change can cause Unionfs to oops, or stay
> > > silent and even RESULT IN DATA LOSS.
> >
> > With a rather rough user
On Mon, 2007-01-08 at 13:00 +0100, Miklos Szeredi wrote:
> > 50% probability of false positive on 4G files seems like very ugly
> > design problem to me.
>
> 4 billion files, each with more than one link is pretty far fetched.
> And anyway, filesystems can take steps to prevent collisions, as the
On Tue, 2007-01-09 at 13:15 +0100, Jan Kara wrote:
> > On Mon, Jan 08, 2007 at 11:18:52AM -0800, Andrew Morton wrote:
> > > On Sun, 7 Jan 2007 23:12:53 -0500
> > > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> > >
>
>
> > > > Any such change can cause Unionfs to oops, or stay
> > > > sile
On Tue, 2007-01-09 at 13:26 +0100, Jan Kara wrote:
> Yes, making fs readonly at VFS level would not work for already opened
> files. But you if you create new union, you could lock down the
> filesystems you are unioning (via s_umount semaphore), go through lists
> of all open fd's on those files
On Tue, 2007-01-09 at 11:30 -0500, Trond Myklebust wrote:
> On Tue, 2007-01-09 at 13:15 +0100, Jan Kara wrote:
> > > On Mon, Jan 08, 2007 at 11:18:52AM -0800, Andrew Morton wrote:
> > > > On Sun, 7 Jan 2007 23:12:53 -0500
> > > > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> > > >
> >
> >
On Tue, 2007-01-09 at 11:41 -0500, Shaya Potter wrote:
> On Tue, 2007-01-09 at 11:30 -0500, Trond Myklebust wrote:
> > You mean somebody like, say, a perfectly innocent process working on the
> > NFS server or some other client that is oblivious to the existence of
> > unionfs stacks on your partic
> On Tue, 2007-01-09 at 13:26 +0100, Jan Kara wrote:
> > Yes, making fs readonly at VFS level would not work for already opened
> > files. But you if you create new union, you could lock down the
> > filesystems you are unioning (via s_umount semaphore), go through lists
> > of all open fd's on t
On Tue, 2007-01-09 at 18:04 +0100, Jan Kara wrote:
> But once you have MS_RDONLY set, there should be no modifications of
> the underlying filesystem, should they? And I have understood that the
> only problem is modifying the filesystem underneath unionfs. But maybe
> I'm missing something.
Rem
In message <[EMAIL PROTECTED]>, Trond Myklebust writes:
> I'm saying that at the very least it should not Oops in these
> situations. As to whether or not they are something you want to handle
> more gracefully, that is up to you, but Oopses are definitely a
> showstopper.
>
> Trond
I totally ag
> On Tue, 2007-01-09 at 11:30 -0500, Trond Myklebust wrote:
> > On Tue, 2007-01-09 at 13:15 +0100, Jan Kara wrote:
> > > > On Mon, Jan 08, 2007 at 11:18:52AM -0800, Andrew Morton wrote:
> > > > > On Sun, 7 Jan 2007 23:12:53 -0500
> > > > > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> > > > >
On Tue, 2007-01-09 at 12:03 -0500, Trond Myklebust wrote:
> I'm saying that at the very least it should not Oops in these
> situations. As to whether or not they are something you want to handle
> more gracefully, that is up to you, but Oopses are definitely a
> showstopper.
I don't think anyone
In message <[EMAIL PROTECTED]>, Jan Kara writes:
> > In message <[EMAIL PROTECTED]>, Andrew Morton writes:
> > > On Sun, 7 Jan 2007 23:12:53 -0500
> > > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> > >
> > > > +Modifying a Unionfs branch directly, while the union is mounted, is
> > > > +curr
In message <[EMAIL PROTECTED]>, Christoph Hellwig writes:
> On Mon, Jan 08, 2007 at 07:03:35PM -0500, Erez Zadok wrote:
> > However, I must caution that a file system like ecryptfs is very different
> > from Unionfs, the latter being a fan-out file system---and both have very
> > different goals.
On Tue, Jan 09, 2007 at 11:26:25AM -0500, Steven Rostedt wrote:
> On Mon, 2007-01-08 at 13:00 +0100, Miklos Szeredi wrote:
>
> > > 50% probability of false positive on 4G files seems like very ugly
> > > design problem to me.
> >
> > 4 billion files, each with more than one link is pretty far fet
On Tue, 9 Jan 2007, Frank van Maarseveen wrote:
>
> Yes but "cp -rl" is typically done by _developers_ and they tend to
> have a better understanding of this (uh, at least within linux context
> I hope so).
>
> Also, just adding hard-links doesn't increase the number of inodes.
No, but it increa
On Mon, Jan 08, 2007 at 07:44:56PM -0500, Josef Sipek wrote:
> Today is a good day!
>
> Andrew Morton included a minimal version of Unionfs in his -mm tree.
>
> This minimal version of the code lacks some of the features in the full
> fledged version, however we'll be cleaning them up and adding th
>but you can get a large number of >1 linked
>files, when you copy full directories with "cp -rl". Which I do a lot
>when developing. I've done that a few times with the Linux tree.
Can you shed some light on how you use this technique? (I.e. what does it
do for you?)
Many people are of the op
On Tue 2007-01-09 15:43:14, Bryan Henderson wrote:
> >but you can get a large number of >1 linked
> >files, when you copy full directories with "cp -rl". Which I do a lot
> >when developing. I've done that a few times with the Linux tree.
>
> Can you shed some light on how you use this technique?
On Tue, Jan 09, 2007 at 03:43:14PM -0800, Bryan Henderson wrote:
> >but you can get a large number of >1 linked
> >files, when you copy full directories with "cp -rl". Which I do a lot
> >when developing. I've done that a few times with the Linux tree.
>
> Can you shed some light on how you use t
On Tue, 9 Jan 2007, Bryan Henderson wrote:
> >but you can get a large number of >1 linked
> >files, when you copy full directories with "cp -rl". Which I do a lot
> >when developing. I've done that a few times with the Linux tree.
>
> Can you shed some light on how you use this technique? (I.e.
On Jan 9 2007 11:41, Shaya Potter wrote:
>
>Again, what about fibre channel support? Imagine I have multiple blades
>connected to a SAN. For whatever reason I format the san w/ ext3 (I've
>actually done this when we didn't need sharing, just needed a huge disk,
>for instance for doing benchmarks
Version 2:
- separate buffer_delay in generic code into buffer_delay
and buffer_unwritten
- include XFS changes as a second patch:
- remove XFS use of buffer_delay to indicate buffer_unwritten
- remove XFS hack to silently clear "lost" unwritten flags
Version 1:
Currently, XFS uses BH_Priv
Don't hide buffer_unwritten behind buffer_delay() and
remove the hack that clears unexpected buffer_unwritten()
states now that it can't happen.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_aops.c | 3 ---
1 file changed, 29 deletions(-)
Index: 2.6.x-xfs-new/fs/xf
On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
> On Thu, 4 Jan 2007 10:26:21 +0530
> Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
>
> Patches against next -mm would be appreciated, please. Sorry about that.
32 matches
Mail list logo
