Andrew,
Thanks for the review comments!
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
On Thu, May 03, 2007 at 09:30:02PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:41:01 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+unsigned int ext4_ext_check_overlap(struct inode *inode,
+ struct ext4_extent *newext,
+
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch has the ext4 implemtation of fallocate system call.
...
+ /* ext4_can_extents_be_merged should have checked that either
+
On Thu, May 03, 2007 at 09:32:38PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:46:23 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+ */
+int ext4_ext_try_to_merge(struct inode *inode,
+ struct ext4_ext_path *path,
+ struct
On Fri, May 04, 2007 at 02:43:21PM +0530, Aneesh Kumar K.V wrote:
+ * unix_cow_io.c --- This is the Unix (well, really POSIX) implementation
+ * of the COW I/O manager.
I really wish you had based this not on unix_io.c, but rather on
test_io.c, for two reasons (a) this reduces code
On Mon, May 07, 2007 at 03:40:26PM +0300, Pekka Enberg wrote:
On 4/26/07, Amit K. Arora [EMAIL PROTECTED] wrote:
/*
+ * ext4_ext_try_to_merge:
+ * tries to merge the ex extent to the next extent in the tree.
+ * It always tries to merge towards right. If you want to merge towards
+ * left,
Jakub Jelinek wrote:
is what glibc does ATM. Seems we violate the case where len == 0, as
EINVAL in that case is shall fail. But reading the standard to imply
negative len is ok is too much guessing, there is no word what it means
when len is negative and
required storage for regular file data
On Mon, May 07, 2007 at 08:56:11AM +0530, Aneesh Kumar K.V wrote:
Andreas Dilger wrote:
If this code could also (or optionally just) increase the size of inodes
it would be very useful. AFAIK right now it will only change the inodes
from block-mapped to extent-mapped?
Actually, changing the
Hi,
Theodore Tso wrote:
On Mon, May 07, 2007 at 08:56:11AM +0530, Aneesh Kumar K.V wrote:
Andreas Dilger wrote:
If this code could also (or optionally just) increase the size of inodes
it would be very useful. AFAIK right now it will only change the inodes
from block-mapped to
Theodore Tso wrote:
That is correct. My next step is to enhance the tool to support
migration to large inodes.
I would actually suggest that the place to add that functionality
would be via tune2fs -I inode_size. Since mke2fs -I inode_size
is used to set the inode size, it makes sense
On Sun, May 06, 2007 at 09:40:14PM -0700, Andrew Morton wrote:
On Mon, 7 May 2007 00:26:26 +0200 Frank van Maarseveen [EMAIL PROTECTED]
wrote:
Steps to reproduce:
Create a 3G partition, say /dev/vol1/project
mke2fs -j -b 4096 /dev/vol1/project 22812
mount it
ext2online
On Mon, May 07, 2007 at 12:26:26AM +0200, Frank van Maarseveen wrote:
2.6.20.6, FC4:
|JBD: ext2online wants too many credits (744 256)
You would be better off using resize2fs from e2fsprogs 1.39, BTW
About the only reason to keep using the ext2resize packages is
ext2prepare, which is
On Mon, 7 May 2007, Theodore Tso wrote:
We're going to have to rethink the defaults of the journal size as it
relates to on-line resizing, but there might not be a lot of great
answers here. We'll also have to look at the on-line resizing code
and see if there's a way to break up the resize
On Mon, 2007-05-07 at 17:37 +0530, Amit K. Arora wrote:
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED]
wrote:
+int ext4_fallocate(struct inode *inode, int mode, loff_t offset, loff_t
len)
+{
+
On Mon, May 07, 2007 at 07:46:38AM -0700, [EMAIL PROTECTED] wrote:
On Mon, 7 May 2007, Theodore Tso wrote:
We're going to have to rethink the defaults of the journal size as it
relates to on-line resizing, but there might not be a lot of great
answers here. We'll also have to look at the
On Mon, May 07, 2007 at 07:16:31PM +0530, Aneesh Kumar K.V wrote:
One of the option i was thinking was to use this tool to migrate to
extent map and then towards the end use the online defrag ioctl to
defrag the resulting ext4 inode.
As we discussed on the phone, my recommendation would be
One of our testers filed a bug that said mkfs.ext3 is much slower when
mke2fs.conf is missing...
This is because the shipped defaults in mke2fs.conf do not match the shipped
defaults in the
mkfs code itself; he wound up making a 1k block filesystem on a very large
block device,
for example.
e2fsprogs doesn't handle large ( 16 bit) UID/GID...
Create an fs by user with large UID:
bash-3.1$ id
uid=501666(newuser) gid=501666(newuser) groups=501666(newuser)
bash-3.1$ /sbin/mke2fs -q fsfile
fsfile is not a block special device.
Proceed anyway? (y,n) y
Now mount it:
[EMAIL PROTECTED]
On Mon, 7 May 2007 11:19:52 -0500
Jose R. Santos [EMAIL PROTECTED] wrote:
I tried the patches and while the tools such as mkfs and debugfs seem
to work fine, I am still unable to mount a filesystem with block
numbers exceeding 32 bits.
Correction,
I tested debugfs on a 32bit blocks
On Mon, May 07, 2007 at 11:31:22AM -0500, Eric Sandeen wrote: One of
our testers filed a bug that said mkfs.ext3 is much slower when
mke2fs.conf is missing...
This is because the shipped defaults in mke2fs.conf do not match the
shipped defaults in the mkfs code itself; he wound up making a
On May 06, 2007 21:40 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 00:26:26 +0200 Frank van Maarseveen [EMAIL PROTECTED]
wrote:
2.6.20.6, FC4:
I created a 91248k ext3 fs with 4k blocksize:
Next, I tried to resize it to about 3G using ext2online while mounted:
At that time
On May 03, 2007 21:31 -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+ * ext4_fallocate:
+ * preallocate space for a file
+ * mode is for future use, e.g. for unallocating preallocated blocks etc.
+ */
This description is rather
Theodore Tso wrote:
On Mon, May 07, 2007 at 11:31:22AM -0500, Eric Sandeen wrote: One of
our testers filed a bug that said mkfs.ext3 is much slower when
mke2fs.conf is missing...
This is because the shipped defaults in mke2fs.conf do not match the
shipped defaults in the mkfs code itself; he
On Mon, 2007-04-30 at 11:14 -0400, Theodore Ts'o wrote:
I've respun the ext4 development patchset, with Amit's updated fallocate
patches. I've added Dave's patch to add ia64 support to the fallocate
system call, but *not* the XFS fallocate support patches. (Probably
better for them to live
On Mon, 7 May 2007 05:37:54 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
+ block = offset blkbits;
+ max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits) blkbits)
+ - block;
+ mutex_lock(EXT4_I(inode)-truncate_mutex);
+ credits =
On May 07, 2007 19:16 +0530, Aneesh Kumar K.V wrote:
Theodore Tso wrote:
Actually, changing the inode size is actually going to be more useful
to a larger number of people, since they can use it today to support
in-inode EA's. In addition, changing the inode size must be done
off-line,
On May 07, 2007 11:50 -0400, Theodore Tso wrote:
On Mon, May 07, 2007 at 07:46:38AM -0700, [EMAIL PROTECTED] wrote:
On Mon, 7 May 2007, Theodore Tso wrote:
We're going to have to rethink the defaults of the journal size as it
relates to on-line resizing, but there might not be a lot of
On May 07, 2007 14:52 -0500, Eric Sandeen wrote:
Theodore Tso wrote:
How likely do you think the case will be that mke2fs.conf would be
missing? I'm trying to figure out how high priority of an item this
really is.
Well, not too likely, although for some reason I guess it happened in
On Mon, 7 May 2007 15:21:04 -0700
Andreas Dilger [EMAIL PROTECTED] wrote:
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that this is the only way to allocate space in the filesystem without
doing the explicit zeroing. For other filesystems (including ext3 and
On Mon, May 07, 2007 at 07:02:32PM -0400, Jeff Garzik wrote:
Andreas Dilger wrote:
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based
On Mon, 2007-05-07 at 13:58 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 05:37:54 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
+ block = offset blkbits;
+ max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits)
blkbits)
+- block;
+
On Mon, 07 May 2007 17:00:24 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
+ while (ret = 0 ret max_blocks) {
+ block = block + ret;
+ max_blocks = max_blocks - ret;
+ ret = ext4_ext_get_blocks(handle, inode, block,
+
On Mon, 2007-05-07 at 16:31 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 19:14:42 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that
On Mon, 2007-05-07 at 17:15 -0700, Andrew Morton wrote:
On Mon, 07 May 2007 17:00:24 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
+ while (ret = 0 ret max_blocks) {
+ block = block + ret;
+ max_blocks = max_blocks - ret;
+ ret =
On May 07, 2007 19:02 -0400, Jeff Garzik wrote:
Andreas Dilger wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only is that this is the only way to allocate space in the
filesystem without doing the explicit zeroing.
Precisely /how/ do you avoid the zeroing
On Mon, May 07, 2007 at 12:10:37PM -0500, Eric Sandeen wrote:
e2fsprogs doesn't handle large ( 16 bit) UID/GID...
Applied, with one correction:
--- e2fsprogs-hg.orig/misc/mke2fs.c
+++ e2fsprogs-hg/misc/mke2fs.c
@@ -492,9 +494,14 @@ static void create_root_dir(ext2_filsys
On Thu, Apr 19, 2007 at 05:35:36PM +0530, Kalpak Shah wrote:
This patch removes a code snippet from check_ea_in_inode() in pass1
which checks if the EA values in the inode are sorted or not. The
comments in fs/ext*/xattr.c state that the EA values in the external
EA block are sorted but those
On Thu, Mar 15, 2007 at 02:43:47AM +0530, Kalpak Shah wrote:
Index: e2fsprogs-1.39/lib/ext2fs/mkjournal.c
===
--- e2fsprogs-1.39.orig/lib/ext2fs/mkjournal.c
+++ e2fsprogs-1.39/lib/ext2fs/mkjournal.c
+ if
39 matches
Mail list logo
