On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> TODO list currently includes following main items:
> * redundancy algorithm (drop me a request of your own, but it is highly
> unlikley that Reed-Solomon based will ever be used - it is too slow
> for distributed RAID, I
On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I'm pleased to announce first release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> Hi.
>
> I'm pleased to announce first release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
> There were heaps of problems in there and it is surprising how few people
> were hitting them. Ordered-mode journalling filesystems will fix it all up
> behind the scenes, of course.
>
> I just have a bad feeling about that code - list_heads are the wrong data
> structure and it all needs to be
Hi!
> > > I wouldn't bother with setting the directory type field to be DT_WHT,
> > > given that they will never be returned to userspace anyway.
> >
> > At the moment I still rely on this for the current readdir implementation.
> > Viro already said that he doesn't want to see this (the readdir
On Thu, 02 Aug 2007 17:52:39 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > The following strange behavior can be observed:
> > >
> > > 1. large file is written
> > > 2. after 30 seconds, nr_dirty goes down by 1024
> > > 3. then for some time (< 30 sec) nothing happens (disk idle)
> > > 4.
On Wed, 1 August 2007 15:33:30 -0400, Josef Sipek wrote:
>
> This brings up an very interesting (but painful) question...which makes more
> sense? Allowing the modifications in only the top-most branch, or any branch
> (given the user allows it at mount-time)?
>
> This is really question to the
Hi Michael,
On Mon, Jul 30, 2007 at 09:44:10PM +0200, Michael Kerrisk wrote:
> Amit, David,
>
> I've edited the previous version of the page, adding David's license, and
> integrating Amit's comments. I've also added a few new FIXMES. ("FIXME
> Amit" again.)
Ok, Thanks!
> Could you please re
> > The following strange behavior can be observed:
> >
> > 1. large file is written
> > 2. after 30 seconds, nr_dirty goes down by 1024
> > 3. then for some time (< 30 sec) nothing happens (disk idle)
> > 4. then nr_dirty again goes down by 1024
> > 5. repeat from 3. until whole file is written
>
On Thu, Aug 02, Ph. Marek wrote:
> On Mittwoch, 1. August 2007, Josef Sipek wrote:
> > Alright not the greatest of examples, there is something to be said about
> > symmetry, so...let me try again :)
> ...
> > Oops! There's a whiteout in /b that hides the directory in /c -- rename(2)
> > shouldn't
On Wed, Aug 01, Erez Zadok wrote:
> There are three other reasons why Unionfs and our users like to have
> multiple writable branches:
>
...
>And yes, it does make our implementation more complex.
And error-prone and unflexible wrt to changes. When XIP was introduced,
unionfs crashed all o
On Wed, Aug 01, Josef Sipek wrote:
> This brings up an very interesting (but painful) question...which makes more
> sense? Allowing the modifications in only the top-most branch, or any branch
> (given the user allows it at mount-time)?
My implementation is keeping things simple because of reason
On Tue, Jul 31, Josef Sipek wrote:
> > So you think that just because you mounted the filesystem somewhere else it
> > should look different? This is what sharing is all about. If you share a
> > filesystem you also share the removal of objects.
>
> The removal happens at the union level, not the
On Thu, Aug 02, Bharata B Rao wrote:
> On Mon, Jul 30, 2007 at 06:13:23PM +0200, Jan Blunck wrote:
> > Here is another post of the VFS based union mount implementation. Unlike the
> > traditional mount which hides the contents of the mount point, union mounts
> > present the merged view of the mou
14 matches
Mail list logo
