Hello Professor Zadok,
Erez Zadok:
> I believe that small VFS changes to help stackable file systems are
> perfectly reasonable, and a good thing; and I'm working on such patches.
> Conversely, I am very mindful of the VFS's complexity, so I also believe
> that massive VFS changes are a bad
Hello Professor Zadok,
Erez Zadok:
I believe that small VFS changes to help stackable file systems are
perfectly reasonable, and a good thing; and I'm working on such patches.
Conversely, I am very mindful of the VFS's complexity, so I also believe
that massive VFS changes are a bad thing; I
Erez Zadok:
> (1) Cache coherency: by far, the biggest concern had been around cache
:::
> unionfs. The solution we have implemented is to compare the mtime/ctime of
> upper/lower objects during revalidation (esp. of dentries); and if the lower
> times are newer, we reconstruct the union
Erez Zadok:
(1) Cache coherency: by far, the biggest concern had been around cache
:::
unionfs. The solution we have implemented is to compare the mtime/ctime of
upper/lower objects during revalidation (esp. of dentries); and if the lower
times are newer, we reconstruct the union
Andreas Dilger:
> > So this looks like 2.6.22 and 2.6.23 material, but the timing is getting
> > pretty squeezy. Could people please give this change an extra-close
> > review, let me know?
>
> I already discussed it at length with Eric and inspected the patch, so we
> could add:
>
Andreas Dilger:
So this looks like 2.6.22 and 2.6.23 material, but the timing is getting
pretty squeezy. Could people please give this change an extra-close
review, let me know?
I already discussed it at length with Eric and inspected the patch, so we
could add:
Signed-off-by: Andreas
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
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
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 surprise
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 for
"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
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:
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
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,
-
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,
- in
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
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).
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
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).
- it
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
Josef Sipek:
> That's the only user of malloc_sizes. It is supposed to be an optimization -
> we get the smallest sized piece of memory even if we don't need all of it.
> This way we don't reallocate & memcpy needlessly.
How about exporting ksize to modules, and introduce a new function such
Josef Sipek:
That's the only user of malloc_sizes. It is supposed to be an optimization -
we get the smallest sized piece of memory even if we don't need all of it.
This way we don't reallocate memcpy needlessly.
How about exporting ksize to modules, and introduce a new function such
like
22 matches
Mail list logo
