On Sep 13 2007 14:52, [EMAIL PROTECTED] wrote:
>Al Boldi:
>> It turns out that the problem was this in dentry.c:
> :::
>> Commenting the #if block makes it compile now.
>>
>> Works great too. Even performance wise. Needs more testing though.
>
>Thank you for your report and forwarding you
Al Boldi:
> It turns out that the problem was this in dentry.c:
:::
> Commenting the #if block makes it compile now.
>
> Works great too. Even performance wise. Needs more testing though.
Thank you for your report and forwarding your original message.
And I am glad that it is working f
to err;
640-}
Commenting the #if block makes it compile now.
Works great too. Even performance wise. Needs more testing though.
You really need to post a cleaned up version for review and possible
inclusion into mainline. It definitely looks solid.
Thanks!
--
Al
-- Original
Jan Engelhardt:
> On Sep 12 2007 13:46, Al Boldi wrote:
::
> >This is way too complicated, but I tried it anyway, only to find it doesn't
> >compile:
>
> cvs up -D 2007-08-07
>
> that one works ;-)
Jan, do you mean that only the one month old version could be compiled?
It it rather sur
On Sep 12 2007 13:46, Al Boldi wrote:
>[EMAIL PROTECTED] wrote:
>> But if you really want to read or try it, you can get all source files
>> from sourceforge. Read http://aufs.sf.net and try,
>> $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/aufs login
>> (CVS password is empty)
>> $ cvs -z3 -d:pserv
[EMAIL PROTECTED] wrote:
> But if you really want to read or try it, you can get all source files
> from sourceforge. Read http://aufs.sf.net and try,
> $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/aufs login
> (CVS password is empty)
> $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/aufs co
> aufs
"Josef 'Jeff' Sipek":
> So, if I understand correctly, you create the entire block as if you were
> going to write to disk? Unionfs keeps the data in a linked list.
Basically yes.
But the dir block in cache has no hole which is contiguous memory.
Junjiro Okajima
-
To unsubscribe from this list:
On Fri, Sep 07, 2007 at 01:54:18PM -0400, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>, "Josef 'Jeff' Sipek" writes:
> > On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote:
> > > On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
> > > >
> > > > When the first read
On Fri, Sep 07, 2007 at 01:39:41PM -0400, Josef 'Jeff' Sipek wrote:
> On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote:
> > On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
> > >
> > > When the first readdir is issued:
> > > - call vfs_readdir for every underlying op
Matt Keenan:
> This sounds like a good approach. How does aufs handle low memory
> situations? Union mounts seem to be quite common on low memory embedded
> systems. Is there a way for the VM to signal to aufs/the union
> filesystem to trim its cache? Also on the memory consumption front I
I also
Hello Jeff,
"Josef 'Jeff' Sipek":
> Unless I missunderstood something, Unionfs uses the same approach. Even
> Unionfs's ODF branch does the same thing. The major difference is that we
> keep the cache in a file on a disk.
The approach unionfs-2.1.2 took differs from mine.
Major difference is,
-
[EMAIL PROTECTED] wrote:
> Hello Bharata,
> I am developing a linux stackable/unification filesystem too.
>
> Bharata B Rao:
>
>> Questions
>> -
>>
> :::
>
>> First of all, should we even expect a sane lseek(2) on union mounted
>> directories ? If not, will the Approach 2,
In message <[EMAIL PROTECTED]>, "Josef 'Jeff' Sipek" writes:
> On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote:
> > On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
> > >
> > > When the first readdir is issued:
> > > - call vfs_readdir for every underlying opened di
On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote:
> On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
> >
> > When the first readdir is issued:
> > - call vfs_readdir for every underlying opened dir (file) object.
> > - store every entry to either the hash table for t
On Sep 7 2007 11:16, Bharata B Rao wrote:
>Questions
>-
>The main problem in getting a sane readdir() implementation in Union Mount
>is the fact that a single vfs object (file structure) is used to represent
>more than one (underlying) directory. Because of this, it is unclear as to
>how l
Al Boldi:
> > If you are interested in this approach, please refer to
> > http://aufs.sf.net. It is working and used by several people.
>
> Any chance you can post a patch against 2.6.22?
Unfortunately there are many reasons to keep me away from sending a
patch.
- it is large (48 source files).
[EMAIL PROTECTED] wrote:
> If you are interested in this approach, please refer to
> http://aufs.sf.net. It is working and used by several people.
Any chance you can post a patch against 2.6.22?
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
>
> When the first readdir is issued:
> - call vfs_readdir for every underlying opened dir (file) object.
> - store every entry to either the hash table for the result or the
> whiteout, when the same-named entry didn't exist in
Hello Bharata,
I am developing a linux stackable/unification filesystem too.
Bharata B Rao:
> Questions
> -
:::
> First of all, should we even expect a sane lseek(2) on union mounted
> directories ? If not, will the Approach 2, which works uniformly for
> all filesystem types be a
Hi,
Any filesystem namespace unification solution (Union Mount, Unionfs) needs to
provide a unified or merged view of directory contents. Typically this is
done by reading the directory entries of all the union'ed layers (starting
from the top and working downwards) and merging the result by elimi
20 matches
Mail list logo
