On Wed, 2006-10-11 12:42:02 +0200, Jan Kara [EMAIL PROTECTED] wrote:
On Sun, 2006-10-08 08:33:30 +0200, Jan-Benedict Glaw [EMAIL PROTECTED]
wrote:
While I could reproduce it with a 200MB file, it seems I can't break
it with a 10MB file.
Hmm, I was running the test for several ours
On Mon, Oct 23, 2006 at 02:27:10PM +0200, Jan Kara wrote:
Hello,
I've written a simple patch implementing ext3 ioctl for file
relocation. Basically you call ioctl on a file, give it list of blocks
and it relocates the file into given blocks (provided they are still
free). The idea is to
Hello,
I've written a simple patch implementing ext3 ioctl for file
relocation. Basically you call ioctl on a file, give it list of blocks
and it relocates the file into given blocks (provided they are still
free). The idea is to use it as a kernel part of ext3 online
defragmenter
On Oct 23, 2006 18:31 +0400, Alex Tomas wrote:
isn't that a kernel responsbility to find/allocate target blocks?
wouldn't it better to specify desirable target group and minimal
acceptable chunk of free blocks?
In some cases this is useful (e.g. if file has small fragments after
being written
Theodore Tso (TT) writes:
TT On Mon, Oct 23, 2006 at 02:27:10PM +0200, Jan Kara wrote:
Hello,
I've written a simple patch implementing ext3 ioctl for file
relocation. Basically you call ioctl on a file, give it list of blocks
and it relocates the file into given blocks
On Oct 23, 2006 18:31 +0400, Alex Tomas wrote:
I would make this interface optionally allow the target extent to be
specified, but if target block == 0 then the kernel is free to do its
own allocation.
That's a good idea! I'll change the handling so that if block==0 we
just allocate blocks
Alex Tomas wrote:
Theodore Tso (TT) writes:
TT On Mon, Oct 23, 2006 at 02:27:10PM +0200, Jan Kara wrote:
Hello,
I've written a simple patch implementing ext3 ioctl for file
relocation. Basically you call ioctl on a file, give it list of blocks
and it relocates the file into given
On Oct 23, 2006 10:16 -0400, Theodore Tso wrote:
As a suggestion, I would pass the inode number and inode generation
number into the ext3_file_mode_data array:
struct ext3_file_move_data {
int extents;
struct ext3_reloc_extent __user *ext_array;
};
This will be much more
On Oct 23, 2006 10:16 -0400, Theodore Tso wrote:
As a suggestion, I would pass the inode number and inode generation
number into the ext3_file_mode_data array:
struct ext3_file_move_data {
int extents;
struct ext3_reloc_extent __user *ext_array;
};
This will be much
On Oct 23, 2006 16:45 +0200, Andre Noll wrote:
stress tests on a 6.3T ext3 filesystem which runs on top of software
raid 6 revealed the following:
[663594.224641] init_special_inode: bogus i_mode (4412)
[663596.355652] init_special_inode: bogus i_mode (5123)
[663596.355832]
On Mon, Oct 23, 2006 at 06:31:40PM +0400, Alex Tomas wrote:
isn't that a kernel responsbility to find/allocate target blocks?
wouldn't it better to specify desirable target group and minimal
acceptable chunk of free blocks?
The kernel doesn't have enough knowledge to know whether or not the
11 matches
Mail list logo
