Jeff Dike wrote:
On Thu, Apr 26, 2007 at 10:53:16AM -0500, Amit Gud wrote:
Jeff Dike wrote:
How about this case:
Growing file starts in chunk A.
Overflows into chunk B.
Delete file in chunk A.
Growing file overflows chunk B and spots new free space in
chunk
Alan Cox wrote:
Preventive measures are taken to limit only one continuation inode per
file per chunk. This can be done easily in the chunk allocation
algorithm for disk space. Although I'm not quite sure what you mean by
How are you handling the allocation in this situation, are you
Jeff Dike wrote:
How about this case:
Growing file starts in chunk A.
Overflows into chunk B.
Delete file in chunk A.
Growing file overflows chunk B and spots new free space in
chunk A (and nothing anywhere else)
Overflows into chunk A
Delete file
Jeff Dike wrote:
How about this case:
Growing file starts in chunk A.
Overflows into chunk B.
Delete file in chunk A.
Growing file overflows chunk B and spots new free space in
chunk A (and nothing anywhere else)
Overflows into chunk A
Delete file
Alan Cox wrote:
Preventive measures are taken to limit only one continuation inode per
file per chunk. This can be done easily in the chunk allocation
algorithm for disk space. Although I'm not quite sure what you mean by
How are you handling the allocation in this situation, are you
Jeff Dike wrote:
On Thu, Apr 26, 2007 at 10:53:16AM -0500, Amit Gud wrote:
Jeff Dike wrote:
How about this case:
Growing file starts in chunk A.
Overflows into chunk B.
Delete file in chunk A.
Growing file overflows chunk B and spots new free space in
chunk
Andreas Dilger wrote:
How do you recover if fsfuzzer takes out a cnode in the chain? The
chunk is marked clean, but clearly corrupted and needs fixing and
you don't know what it was pointing at. Hence you have a pointer to
a trashed cnode *somewhere* that you need to find and fix, and a
bunch
Andreas Dilger wrote:
How do you recover if fsfuzzer takes out a cnode in the chain? The
chunk is marked clean, but clearly corrupted and needs fixing and
you don't know what it was pointing at. Hence you have a pointer to
a trashed cnode *somewhere* that you need to find and fix, and a
bunch
Nikita Danilov wrote:
Maybe I failed to describe the problem presicely.
Suppose that all chunks have been checked. After that, for every inode
I0 having continuations I1, I2, ... In, one has to check that every
logical block is presented in at most one of these inodes. For this one
has to read
Nikita Danilov wrote:
Maybe I failed to describe the problem presicely.
Suppose that all chunks have been checked. After that, for every inode
I0 having continuations I1, I2, ... In, one has to check that every
logical block is presented in at most one of these inodes. For this one
has to read
On Mon, 23 Apr 2007, Amit Gud wrote:
On Mon, 23 Apr 2007, Arjan van de Ven wrote:
> The other thing which we should consider is that chunkfs really
> requires a 64-bit inode number space, which means either we only allow
does it?
I'd think it needs a "chunk space" num
Suparna Bhattacharya wrote:
Could you send this out as a patch to ext2 codebase, so we can just look
at the changes for chunkfs ? That might also make it small enough
to inline your patch in email for review.
What kind of results are you planning to gather to evaluate/optimize this ?
This is an initial implementation of ChunkFS technique, briefly discussed
at: http://lwn.net/Articles/190222 and
http://cis.ksu.edu/~gud/docs/chunkfs-hotdep-val-arjan-gud-zach.pdf
This implementation is done within ext2 driver. Every chunk is an
independent ext2 file system. The knowledge
This is an initial implementation of ChunkFS technique, briefly discussed
at: http://lwn.net/Articles/190222 and
http://cis.ksu.edu/~gud/docs/chunkfs-hotdep-val-arjan-gud-zach.pdf
This implementation is done within ext2 driver. Every chunk is an
independent ext2 file system. The knowledge
Suparna Bhattacharya wrote:
Could you send this out as a patch to ext2 codebase, so we can just look
at the changes for chunkfs ? That might also make it small enough
to inline your patch in email for review.
What kind of results are you planning to gather to evaluate/optimize this ?
On Mon, 23 Apr 2007, Amit Gud wrote:
On Mon, 23 Apr 2007, Arjan van de Ven wrote:
The other thing which we should consider is that chunkfs really
requires a 64-bit inode number space, which means either we only allow
does it?
I'd think it needs a chunk space number and a 32 bit local
Karuna sagar K wrote:
Hi,
The attached code contains program to estimate the cross-chunk
references for ChunkFS file system (idea from Valh). Below are the
results:
Nice to see some numbers! But would be really nice to know:
- what the chunk size is
- how the files were created or, more
Karuna sagar K wrote:
Hi,
The attached code contains program to estimate the cross-chunk
references for ChunkFS file system (idea from Valh). Below are the
results:
Nice to see some numbers! But would be really nice to know:
- what the chunk size is
- how the files were created or, more
Unify the spinlock initialization as far as possible.
Do consider applying.
Signed-off-by: Amit Gud <[EMAIL PROTECTED]>
--- orig/include/linux/wait.h 2005-01-20 20:06:42.0 +0530
+++ linux-2.6.11-rc2/include/linux/wait.h 2005-01-25 16:41:31.0
+0530
@@ -79,7
Unify the spinlock initialization as far as possible.
Do consider applying.
Signed-off-by: Amit Gud <[EMAIL PROTECTED]>
--- orig/arch/mips/kernel/irq.c 2005-01-20 20:06:12.0 +0530
+++ linux-2.6.11-rc2/arch/mips/kernel/irq.c 2005-01-25 15:29:35.0
+0530
@@ -125,7
Unify the spinlock initialization as far as possible.
Do consider applying.
Signed-off-by: Amit Gud [EMAIL PROTECTED]
--- orig/arch/mips/kernel/irq.c 2005-01-20 20:06:12.0 +0530
+++ linux-2.6.11-rc2/arch/mips/kernel/irq.c 2005-01-25 15:29:35.0
+0530
@@ -125,7 +125,7 @@ void
Unify the spinlock initialization as far as possible.
Do consider applying.
Signed-off-by: Amit Gud [EMAIL PROTECTED]
--- orig/include/linux/wait.h 2005-01-20 20:06:42.0 +0530
+++ linux-2.6.11-rc2/include/linux/wait.h 2005-01-25 16:41:31.0
+0530
@@ -79,7 +79,7
22 matches
Mail list logo
