[RFC][PATCH 1/3] Allocate new contiguous blocks

2007-02-08 Thread Takashi Sato
Search contiguous free blocks with Alex's mutil-block allocation and allocate them for the temporary inode. This patch applies on top of Alex's patches. [RFC] delayed allocation, mballoc, etc http://marc.theaimsgroup.com/?l=linux-ext4m=116493228301966w=2 Signed-off-by: Takashi Sato [EMAIL

[RFC][PATCH 2/3] Move the file data to the new blocks

2007-02-08 Thread Takashi Sato
Move the blocks on the temporary inode to the original inode by a page. 1. Read the file data from the old blocks to the page 2. Move the block on the temporary inode to the original inode 3. Write the file data on the page into the new blocks Signed-off-by: Takashi Sato [EMAIL PROTECTED] ---

Re: [RFC][PATCH 2/3] Move the file data to the new blocks

2007-02-08 Thread Andrew Morton
On Thu, 8 Feb 2007 10:29:45 +0100 Jan Kara [EMAIL PROTECTED] wrote: On Wed 07-02-07 12:56:59, Andrew Morton wrote: On Wed, 7 Feb 2007 13:46:57 -0700 Andreas Dilger [EMAIL PROTECTED] wrote: On Feb 06, 2007 17:35 -0800, Andrew Morton wrote: On Mon, 5 Feb 2007 14:12:04 +0100 Jan

Re: [RFC][PATCH 2/3] Move the file data to the new blocks

2007-02-08 Thread Jan Kara
On Thu 08-02-07 01:45:29, Andrew Morton wrote: snip I though Andreas meant any write changes - i.e. you check that noone has open file descriptor for writing and block any new open for writing. That can be done quite easily. Anyway, I agree with you that userspace solution to a

Re: [RFC] [PATCH 1/1] Nanosecond timestamps

2007-02-08 Thread Johann Lombardi
On Wed, Feb 07, 2007 at 01:39:46PM -0700, Andreas Dilger wrote: This has been a bug in several places already, and I wonder if the le*_to_cpu() and cpu_to_le*() macros shouldn't do some type checking instead of just casting the variable to the specified type? That would be great. The only

Re: [RFC] [PATCH 1/1] Nanosecond timestamps

2007-02-08 Thread Johann Lombardi
On Wed, Feb 07, 2007 at 03:05:39PM -0600, Dave Kleikamp wrote: On Wed, 2007-02-07 at 13:39 -0700, Andreas Dilger wrote: You are right - this works fine on little endian systems, but fails on big endian systems where you will get the other half of the word. This has been a bug in several

Re: [RFC][PATCH 2/3] Move the file data to the new blocks

2007-02-08 Thread Andrew Morton
On Thu, 8 Feb 2007 11:21:02 +0100 Jan Kara [EMAIL PROTECTED] wrote: On Thu 08-02-07 01:45:29, Andrew Morton wrote: snip I though Andreas meant any write changes - i.e. you check that noone has open file descriptor for writing and block any new open for writing. That can be done

Re: [RFC][PATCH 2/3] Move the file data to the new blocks

2007-02-08 Thread Jan Kara
On Thu 08-02-07 02:32:13, Andrew Morton wrote: On Thu, 8 Feb 2007 11:21:02 +0100 Jan Kara [EMAIL PROTECTED] wrote: On Thu 08-02-07 01:45:29, Andrew Morton wrote: snip I though Andreas meant any write changes - i.e. you check that noone has open file descriptor for writing and

Re: [RFC][PATCH 3/3] Online defrag command

2007-02-08 Thread Jens Axboe
On Thu, Feb 08 2007, Takashi Sato wrote: The defrag command. Usage is as follows: o Put the multiple files closer together. # e4defrag -r directory-name o Defrag for a single file. # e4defrag file-name o Defrag for all files on ext4. # e4defrag device-name Would it be possible to

[PATCH] e2fsck journal recovery can corrupt all superblock backups

2007-02-08 Thread Andreas Dilger
Ted, this was sent with the first patch, and it looks like it is a very serious problem. Looking through the e2fsck code it would also seem possible to move the setting of EXT2_FLAG_MASTER_SB_ONLY before the journal replay. That is the second patch. I'm not sure which one is better. Jim