Re: [PATCH] Introduce ext4_find_next_bit
On Fri, 21 Sep 2007 10:55:05 +0530 "Aneesh Kumar K.V" <[EMAIL PROTECTED]> wrote: > Also add generic_find_next_le_bit > > This gets used by the ext4 multi block allocator patches. > arm allmodconfig: fs/ext4/mballoc.c: In function `ext4_mb_generate_buddy': fs/ext4/mballoc.c:836: error: implicit declaration of function `ext2_find_next_bit' This patch makes my head spin. Why did we declare generic_find_next_le_bit() in include/asm-powerpc/bitops.h (wrong) as well as in include/asm-generic/bitops/le.h (presumably correct)? Why is it touching a powerpc file and no any other architectures? Something screwed up in powerpc land? And why did arm break? Shudder. Anyway, please fix, and if that fix requires that various braindamaged be repaired, please repair the braindamage rather than going along with it. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] FIEMAP ioctl for ext4
On Tue, Nov 13, 2007 at 02:30:06AM +0530, Kalpak Shah wrote:
> Recently there was discussion about an "FIle Extent MAP"(FIEMAP) ioctl for
> efficiently mapping the extents and holes of a file. This will be many times
> more efficient than FIBMAP by cutting down the number of ioctls.
>
> This patch adds the FIEMAP ioctl for ext4. The spec for the FIEMAP ioctl was
> posted earlier by Andreas Dilger and can be found at:
> http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg03944.html
> }
> + case EXT4_IOC_FIEMAP: {
> + return ext4_fiemap(inode, filp, cmd, arg);
> + }
>
> default:
> return -ENOTTY;
> Index: linux-2.6.23.1/include/linux/ext4_fs.h
> ===
> --- linux-2.6.23.1.orig/include/linux/ext4_fs.h
> +++ linux-2.6.23.1/include/linux/ext4_fs.h
> @@ -228,15 +228,20 @@ struct ext4_new_group_data {
> #define EXT4_IOC_SETFLAGS FS_IOC_SETFLAGS
> #define EXT4_IOC_GETVERSION _IOR('f', 3, long)
> #define EXT4_IOC_SETVERSION _IOW('f', 4, long)
> +#define EXT4_IOC_GETRSVSZ_IOR('f', 5, long)
> +#define EXT4_IOC_SETRSVSZ_IOW('f', 6, long)
> #define EXT4_IOC_GROUP_EXTEND_IOW('f', 7, unsigned long)
> #define EXT4_IOC_GROUP_ADD _IOW('f', 8,struct ext4_new_group_input)
> +#define EXT4_IOC_FIEMAP _IOWR('f', 10, struct fiemap)
Please make this common - we dont want a new ioctl for every
filesystem; we want a single common to all filesystems.
> +int ext4_fiemap(struct inode *inode, struct file *filp, unsigned int cmd,
> + unsigned long arg)
> +{
Most of this function will be common to all IOC_FIEMAP
implementations.
> + struct fiemap *fiemap_s;
> + struct fiemap_internal fiemap_i;
> + struct fiemap_extent *last_extent;
> + ext4_fsblk_t start_blk;
> + int fm_extent_size = sizeof(struct fiemap_extent);
> + int err = 0;
> +
> + if (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))
> + return -EOPNOTSUPP;
struct address_space *mapping = filp->f_mapping;
if (!mapping->a_ops->fiemap)
return -EOPNOTSUPP;
> +
> + fiemap_s = kmalloc(sizeof(*fiemap_s), GFP_KERNEL);
> + if (fiemap_s == NULL)
> + return -ENOMEM;
> + if (copy_from_user(fiemap_s, (struct fiemap __user *)arg,
> +sizeof(*fiemap_s)))
> + return -EFAULT;
This is common
> +
> + if (fiemap_s->fm_flags & EXT4_FIEMAP_FLAG_INCOMPAT_UNSUPP)
> + return -EOPNOTSUPP;
> +
> + if (fiemap_s->fm_flags & FIEMAP_FLAG_SYNC)
> + ext4_sync_file(filp, filp->f_dentry, 1);
The common form is:
if (fiemap_s->fm_flags & FIEMAP_FLAG_SYNC)
filemap_write_and_wait(mapping);
> + start_blk = fiemap_s->fm_start >> inode->i_sb->s_blocksize_bits;
> + fiemap_i.fiemap_s = fiemap_s;
> + fiemap_i.tot_mapping_len = 0;
> + fiemap_i.cur_ext_ptr = (char *)(arg + sizeof(*fiemap_s));
> + fiemap_i.current_extent = 0;
> + fiemap_i.err = 0;
Seems common.
> +
> + /*
> + * Walk the extent tree gathering extent information
> + */
> + mutex_lock(&EXT4_I(inode)->truncate_mutex);
> + err = ext4_ext_walk_space(inode, start_blk , EXT_MAX_BLOCK - start_blk,
> + ext4_ext_fiemap_cb, &fiemap_i);
> + mutex_unlock(&EXT4_I(inode)->truncate_mutex);
This becomes:
error = mapping->a_ops->fiemap(inode, );
and the lock, extent walk, etc becomes ext4_fiemap() which is set up
in the a_ops for the filesystem. Any filesystems specific checks go
there as well.
> + if (err)
> + return err;
> +
> + fiemap_s->fm_extent_count = fiemap_i.current_extent;
> + fiemap_s->fm_length = fiemap_i.tot_mapping_len;
> + /*
> + * Mark last extent as EXTENT_LAST and copy the extent to userspace.
> + */
> + if (fiemap_i.current_extent != 0 &&
> + fiemap_i.current_extent < fiemap_s->fm_extent_count &&
> + !(fiemap_s->fm_flags & FIEMAP_FLAG_NUM_EXTENTS)) {
> + char *dest;
> +
> + last_extent = &fiemap_i.fm_extent;
> + last_extent->fe_flags |= FIEMAP_EXTENT_LAST;
> + dest = (char *)arg + sizeof(*fiemap_s) + fm_extent_size *
> + (fiemap_s->fm_extent_count - 1);
> + err = copy_to_user(dest, last_extent, fm_extent_size);
> + if (err)
> + return err;
> + }
> + err = copy_to_user((void *)arg, fiemap_s, sizeof(*fiemap_s));
> +
> + return err;
That's common, too.
I don't want to see this implemented over and over again with minute
variations and bugs. The common implementation should be called from
in do_file_ioctl() like FIBMAP
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsub
Re: [PATCH 1/2] Add FIEMAP header file
On Tue, Nov 13, 2007 at 02:30:02AM +0530, Kalpak Shah wrote:
> Recently there was discussion about an "FIle Extent MAP"(FIEMAP) ioctl for
> efficiently mapping the extents and holes of a file. This will be many
> times more efficient than FIBMAP by cutting down the number of ioctls.
Thanks for sending this out.
> This patch adds the FIEMAP header file in include/linux.
Any problem with defining the IOC_FIEMAP ioctl number in this header too? No
EXT4 prefix so we keep things generic too, please.
--Mark
> Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
> Signed-off-by: Kalpak Shah <[EMAIL PROTECTED]>
>
> Index: linux-2.6.23.1/include/linux/fiemap.h
> ===
> --- /dev/null
> +++ linux-2.6.23.1/include/linux/fiemap.h
> @@ -0,0 +1,49 @@
> +/*
> + * include/linux/fiemap.h
> + *
> + * Copyright (C) 2007 Sun Microsystems, Inc.
> + *
> + * Author: Kalpak Shah <[EMAIL PROTECTED]>
> + * Andreas Dilger <[EMAIL PROTECTED]>
> + */
> +
> +#ifndef _LINUX_FIEMAP_H
> +#define _LINUX_FIEMAP_H
> +
> +struct fiemap_extent {
> + __u64 fe_offset; /* offset in bytes for the start of the extent */
> + __u64 fe_length; /* length in bytes for the extent */
> + __u32 fe_flags; /* returned FIEMAP_EXTENT_* flags for the extent */
> + __u32 fe_lun;/* logical device number for extent (starting at 0)*/
> +};
> +
> +struct fiemap {
> + __u64 fm_start;/* logical starting byte offset (in/out) */
> + __u64 fm_length; /* logical length of map (in/out) */
> + __u32 fm_flags;/* FIEMAP_FLAG_* flags for request (in/out) */
> + __u32 fm_extent_count; /* number of extents in fm_extents (in/out) */
> + __u64 fm_end_offset; /* logical offset of end of mapping in last
> ioctl */
> + struct fiemap_extentfm_extents[0];
> +};
> +
> +#define FIEMAP_FLAG_SYNC 0x0001 /* sync file data before map */
> +#define FIEMAP_FLAG_HSM_READ 0x0002 /* get data from HSM before map */
> +#define FIEMAP_FLAG_NUM_EXTENTS 0x0004 /* return only number of
> extents */
> +#define FIEMAP_FLAG_INCOMPAT 0xff00 /* error for unknown flags in here */
> +
> +#define FIEMAP_FLAG_LUN_OFFSET 0x0100 /* use lun offsets, instead
> of
> + * logical file offsets */
> +
> +#define FIEMAP_EXTENT_HOLE 0x0001 /* has no data or space allocation */
> +#define FIEMAP_EXTENT_UNWRITTEN 0x0002 /* space allocated, but no
> data */
> +#define FIEMAP_EXTENT_UNMAPPED 0x0004 /* has data but no space
> allocation*/
> +#define FIEMAP_EXTENT_ERROR 0x0008 /* mapping error, errno in fe_start*/
> +#define FIEMAP_EXTENT_NO_DIRECT 0x0010 /* cannot access data
> directly */
> +#define FIEMAP_EXTENT_LAST 0x0020 /* last extent in the file */
> +#define FIEMAP_EXTENT_DELALLOC 0x0040 /* has data but not yet
> written,
> + * must have EXTENT_UNKNOWN set */
> +#define FIEMAP_EXTENT_SECONDARY 0x0080 /* data (also) in secondary
> storage,
> + * not in primary if EXTENT_UNKNOWN*/
> +#define FIEMAP_EXTENT_EOF0x0100 /* if fm_start+fm_len is beyond EOF*/
> +
> +#endif /* _LINUX_FIEMAP_H */
>
--
Mark Fasheh
Senior Software Developer, Oracle
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add FIEMAP header file
Recently there was discussion about an "FIle Extent MAP"(FIEMAP) ioctl for
efficiently mapping the extents and holes of a file. This will be many times
more efficient than FIBMAP by cutting down the number of ioctls.
This patch adds the FIEMAP header file in include/linux.
Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
Signed-off-by: Kalpak Shah <[EMAIL PROTECTED]>
Index: linux-2.6.23.1/include/linux/fiemap.h
===
--- /dev/null
+++ linux-2.6.23.1/include/linux/fiemap.h
@@ -0,0 +1,49 @@
+/*
+ * include/linux/fiemap.h
+ *
+ * Copyright (C) 2007 Sun Microsystems, Inc.
+ *
+ * Author: Kalpak Shah <[EMAIL PROTECTED]>
+ *Andreas Dilger <[EMAIL PROTECTED]>
+ */
+
+#ifndef _LINUX_FIEMAP_H
+#define _LINUX_FIEMAP_H
+
+struct fiemap_extent {
+ __u64 fe_offset; /* offset in bytes for the start of the extent */
+ __u64 fe_length; /* length in bytes for the extent */
+ __u32 fe_flags; /* returned FIEMAP_EXTENT_* flags for the extent */
+ __u32 fe_lun;/* logical device number for extent (starting at 0)*/
+};
+
+struct fiemap {
+ __u64 fm_start;/* logical starting byte offset (in/out) */
+ __u64 fm_length; /* logical length of map (in/out) */
+ __u32 fm_flags;/* FIEMAP_FLAG_* flags for request (in/out) */
+ __u32 fm_extent_count; /* number of extents in fm_extents (in/out) */
+ __u64 fm_end_offset; /* logical offset of end of mapping in last
ioctl */
+ struct fiemap_extentfm_extents[0];
+};
+
+#define FIEMAP_FLAG_SYNC 0x0001 /* sync file data before map */
+#define FIEMAP_FLAG_HSM_READ 0x0002 /* get data from HSM before map */
+#define FIEMAP_FLAG_NUM_EXTENTS0x0004 /* return only number of
extents */
+#define FIEMAP_FLAG_INCOMPAT 0xff00 /* error for unknown flags in here */
+
+#define FIEMAP_FLAG_LUN_OFFSET 0x0100 /* use lun offsets, instead of
+ * logical file offsets */
+
+#define FIEMAP_EXTENT_HOLE 0x0001 /* has no data or space allocation */
+#define FIEMAP_EXTENT_UNWRITTEN0x0002 /* space allocated, but no
data */
+#define FIEMAP_EXTENT_UNMAPPED 0x0004 /* has data but no space allocation*/
+#define FIEMAP_EXTENT_ERROR0x0008 /* mapping error, errno in fe_start*/
+#define FIEMAP_EXTENT_NO_DIRECT0x0010 /* cannot access data
directly */
+#define FIEMAP_EXTENT_LAST 0x0020 /* last extent in the file */
+#define FIEMAP_EXTENT_DELALLOC 0x0040 /* has data but not yet written,
+ * must have EXTENT_UNKNOWN set */
+#define FIEMAP_EXTENT_SECONDARY0x0080 /* data (also) in secondary
storage,
+ * not in primary if EXTENT_UNKNOWN*/
+#define FIEMAP_EXTENT_EOF 0x0100 /* if fm_start+fm_len is beyond EOF*/
+
+#endif /* _LINUX_FIEMAP_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH e2fsprogs] filefrag using FIEMAP
This patch adds FIEMAP support to the filefrag utility. It also changes the
output format of filefrag by adding a "-e" option. This would make the output
more readable and easy for scripting.
For cluster filesystems like Lustre, the extent information will be displayed
in lun offset order.
Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
Signed-off-by: Kalpak Shah <[EMAIL PROTECTED]>
Index: e2fsprogs-1.40.2/misc/filefrag.c
===
--- e2fsprogs-1.40.2.orig/misc/filefrag.c
+++ e2fsprogs-1.40.2/misc/filefrag.c
@@ -38,13 +38,24 @@ extern int optind;
#include
#include
#include
+#include
+#include
-int verbose = 0;
+#define LUSTRE_SUPER_MAGIC 0x0BD00BD0
-#define FIBMAP_IO(0x00,1) /* bmap access */
-#define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */
+int verbose = 0;
+int extent_format = 0; /* Print output in extent format */
+int is_lustre = 0; /* Indicates lustre filesystem */
+int lun_offset = 0; /* extents are in lun offset order */
+
+#define FILEFRAG_FIEMAP_INCOMPAT_UNSUPP (FIEMAP_FLAG_INCOMPAT & \
+ ~(FIEMAP_FLAG_LUN_OFFSET))
+
+#define FIBMAP _IO(0x00, 1)/* bmap access */
+#define FIGETBSZ _IO(0x00, 2)/* get the block size used for bmap */
+#define EXT4_IOC_FIEMAP_IOWR('f', 10, struct fiemap) /* get file
extent info*/
-#define EXT4_EXTENTS_FL0x0008 /* Inode uses
extents */
+#defineEXT4_EXTENTS_FL 0x0008 /* Inode uses
extents */
#defineEXT3_IOC_GETFLAGS _IOR('f', 1, long)
static unsigned int div_ceil(unsigned int a, unsigned int b)
@@ -54,21 +65,168 @@ static unsigned int div_ceil(unsigned in
return ((a - 1) / b) + 1;
}
-static unsigned long get_bmap(int fd, unsigned long block)
+static int get_bmap(int fd, unsigned long block, unsigned long *phy_blk)
{
int ret;
unsigned int b;
b = block;
- ret = ioctl(fd, FIBMAP, &b); /* FIBMAP takes a pointer to an integer */
+ ret = ioctl(fd, FIBMAP, &b); /* FIBMAP takes pointer to integer */
if (ret < 0) {
if (errno == EPERM) {
- fprintf(stderr, "No permission to use FIBMAP ioctl;
must have root privileges\n");
+ fprintf(stderr, "No permission to use FIBMAP ioctl; "
+ "must have root privileges\n");
exit(1);
}
perror("FIBMAP");
}
- return b;
+ *phy_blk = b;
+
+ return ret;
+}
+
+static void print_extent_info(struct fiemap_extent *fm_extent, int cur_ex,
+ unsigned long long logical_blk, int bs)
+{
+ __u64 phy_blk;
+ unsigned long ext_len;
+ char flags[256] = "";
+
+ phy_blk = fm_extent->fe_offset / bs;
+ ext_len = fm_extent->fe_length / bs;
+
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_HOLE)
+ strcat(flags, "hole,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_EOF)
+ strcat(flags, "eof,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_DELALLOC)
+ strcat(flags, "delalloc,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_UNWRITTEN)
+ strcat(flags, "unwritten,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_UNMAPPED)
+ strcat(flags, "unmapped,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_SECONDARY)
+ strcat(flags, "secondary,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_NO_DIRECT)
+ strcat(flags, "no_direct,");
+ if (fm_extent->fe_flags & FIEMAP_EXTENT_ERROR)
+ strcat(flags, "mapping_error");
+
+ /* Remove trailing comma, if any */
+ if (strlen(flags))
+ flags[strlen(flags) - 1] = '\0';
+
+ printf("%5d:%10llu..%10llu:%10llu..%10llu:%10lu:%3d: %s\n",
+ cur_ex, logical_blk, logical_blk + ext_len - 1,
+ phy_blk, phy_blk ? phy_blk + ext_len : 0, ext_len,
+ fm_extent->fe_lun, flags);
+}
+
+int filefrag_fiemap(int fd, int bs, int *num_extents)
+{
+ char buf[4096] = "";
+ struct fiemap *fiemap = (struct fiemap *)buf;
+ int count = (sizeof(buf) - sizeof(*fiemap)) /
+ sizeof(struct fiemap_extent);
+ unsigned long long logical_blk = 0, last_blk = 0;
+ unsigned long flags = 0;
+ int lun_offset_tried = 0;
+ int tot_extents = 0, previous_lun = 0;
+ int last = 0, eof = 0;
+ int i, rc;
+
+ memset(fiemap, 0, sizeof(struct fiemap));
+ fiemap->fm_extent_count = count;
+ fiemap->fm_length = ~0ULL;
+
+ if (lun_offset)
+ flags |= FIEMAP_FLAG_LUN_OFFSET;
+
+ if (!verbose)
+ flags |= FIEMAP_FLAG_NUM_EXTENTS;
+
+ if (extent_format && verbose)
+ printf(" ext:\tlogical: start..
[PATCH 2/2] FIEMAP ioctl for ext4
Recently there was discussion about an "FIle Extent MAP"(FIEMAP) ioctl for
efficiently mapping the extents and holes of a file. This will be many times
more efficient than FIBMAP by cutting down the number of ioctls.
This patch adds the FIEMAP ioctl for ext4. The spec for the FIEMAP ioctl was
posted earlier by Andreas Dilger and can be found at:
http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg03944.html
Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
Signed-off-by: Kalpak Shah <[EMAIL PROTECTED]>
Index: linux-2.6.23.1/fs/ext4/ioctl.c
===
--- linux-2.6.23.1.orig/fs/ext4/ioctl.c
+++ linux-2.6.23.1/fs/ext4/ioctl.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
int ext4_ioctl (struct inode * inode, struct file * filp, unsigned int cmd,
unsigned long arg)
@@ -248,6 +249,9 @@ flags_err:
return err;
}
+ case EXT4_IOC_FIEMAP: {
+ return ext4_fiemap(inode, filp, cmd, arg);
+ }
default:
return -ENOTTY;
Index: linux-2.6.23.1/include/linux/ext4_fs.h
===
--- linux-2.6.23.1.orig/include/linux/ext4_fs.h
+++ linux-2.6.23.1/include/linux/ext4_fs.h
@@ -228,15 +228,20 @@ struct ext4_new_group_data {
#defineEXT4_IOC_SETFLAGS FS_IOC_SETFLAGS
#defineEXT4_IOC_GETVERSION _IOR('f', 3, long)
#defineEXT4_IOC_SETVERSION _IOW('f', 4, long)
+#define EXT4_IOC_GETRSVSZ _IOR('f', 5, long)
+#define EXT4_IOC_SETRSVSZ _IOW('f', 6, long)
#define EXT4_IOC_GROUP_EXTEND _IOW('f', 7, unsigned long)
#define EXT4_IOC_GROUP_ADD _IOW('f', 8,struct ext4_new_group_input)
+#define EXT4_IOC_FIEMAP_IOWR('f', 10, struct fiemap)
#defineEXT4_IOC_GETVERSION_OLD FS_IOC_GETVERSION
#defineEXT4_IOC_SETVERSION_OLD FS_IOC_SETVERSION
#ifdef CONFIG_JBD2_DEBUG
#define EXT4_IOC_WAIT_FOR_READONLY _IOR('f', 99, long)
#endif
-#define EXT4_IOC_GETRSVSZ _IOR('f', 5, long)
-#define EXT4_IOC_SETRSVSZ _IOW('f', 6, long)
+
+/* ext4 only handles a single LUN, ignore LUN_OFFSET flag */
+#define EXT4_FIEMAP_FLAG_INCOMPAT_UNSUPP (FIEMAP_FLAG_INCOMPAT & \
+ ~(FIEMAP_FLAG_LUN_OFFSET))
/*
* ioctl commands in 32 bit emulation
@@ -1067,6 +1072,8 @@ ext4_get_blocks_wrap(handle_t *handle, s
return ext4_get_blocks_handle(handle, inode, block, max_blocks, bh,
create, extend_disksize);
}
+extern int ext4_fiemap(struct inode *inode, struct file *filp, unsigned int
cmd,
+ unsigned long arg);
#endif /* __KERNEL__ */
Index: linux-2.6.23.1/include/linux/ext4_fs_extents.h
===
--- linux-2.6.23.1.orig/include/linux/ext4_fs_extents.h
+++ linux-2.6.23.1/include/linux/ext4_fs_extents.h
@@ -131,8 +131,8 @@ struct ext4_ext_path {
* callback must return valid extent (passed or newly created)
*/
typedef int (*ext_prepare_callback)(struct inode *, struct ext4_ext_path *,
- struct ext4_ext_cache *,
- void *);
+ struct ext4_ext_cache *,
+ struct ext4_extent *, void *);
#define EXT_CONTINUE 0
#define EXT_BREAK 1
Index: linux-2.6.23.1/fs/ext4/extents.c
===
--- linux-2.6.23.1.orig/fs/ext4/extents.c
+++ linux-2.6.23.1/fs/ext4/extents.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
@@ -1512,7 +1513,7 @@ int ext4_ext_walk_space(struct inode *in
}
BUG_ON(cbex.ec_len == 0);
- err = func(inode, path, &cbex, cbdata);
+ err = func(inode, path, &cbex, ex, cbdata);
ext4_ext_drop_refs(path);
if (err < 0)
@@ -2629,3 +2630,163 @@ retry:
return ret > 0 ? ret2 : ret;
}
+
+struct fiemap_internal {
+ struct fiemap *fiemap_s;
+ struct fiemap_extentfm_extent;
+ size_t tot_mapping_len;
+ char*cur_ext_ptr;
+ int current_extent;
+ int err;
+};
+
+/*
+ * Callback function called for each extent to gather FIEMAP information.
+ */
+int ext4_ext_fiemap_cb(struct inode *inode, struct ext4_ext_path *path,
+ struct ext4_ext_cache *newex, struct ext4_extent *ex,
+ void *data)
+{
+ struct fiemap_internal *fiemap_i = data;
+ struct fiemap *fiemap_s = fiemap_i->fiemap_s;
+ struct fiemap_extent *fm_extent = &fiemap_i->fm_extent;
+ int current_extent = fiemap_i-
Re: Oops 2.6.23.1 in ext3+jbd at journal_put_journal_head
Mark Lord wrote: A one-time event thus far, happened under very heavy I/O, Dell i9400 Core2Duo notebook w/3GB ram, single SATA drive with ext3. Had to cycle power to get it back and see this Oops in the syslog: : BUG: unable to handle kernel paging request at virtual address 430a7261 ... Note that the drive is clean, no bad sectors, no errors in S.M.A.R.T. logs. - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Oops 2.6.23.1 in ext3+jbd at journal_put_journal_head
A one-time event thus far, happened under very heavy I/O, Dell i9400 Core2Duo notebook w/3GB ram, single SATA drive with ext3. Had to cycle power to get it back and see this Oops in the syslog: : BUG: unable to handle kernel paging request at virtual address 430a7261 : printing eip: : c01a6605 : *pde = : Oops: 0002 [#1] : PREEMPT SMP : Modules linked in: nls_iso8859_1 vfat fat usb_storage ide_core libusual hci_usb ext2 loop nls_cp437 isofs zlib_inflate udf vmnet(P) vmblock(P) vmmon(P) binfmt_misc rfcomm l2cap bluetooth nfs nfsd exportfs lockd nfs_acl auth_rpcgss sunrpc acpi_cpufreq cpufreq_stats cpufreq_userspace cpufreq_ondemand cpufreq_conservative freq_table cpufreq_powersave container fan firmware_class af_packet pciehp usbhid hid pci_hotplug visor usbserial fuse mousedev snd_hda_intel snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event serio_raw snd_seq snd_timer snd_seq_device sg thermal firewire_ohci snd pcspkr sr_mod cdrom psmouse firewire_core sdhci mmc_core b44 mii crc_itu_t ac uhci_hcd ehci_hcd intel_agp agpgart processor button soundcore snd_page_alloc usbcore battery unix : CPU:1 : EIP:0060:[journal_put_journal_head+64/209]Tainted: PVLI : EFLAGS: 00010202 (2.6.23.1-slab #15) : EIP is at journal_put_journal_head+0x40/0xd1 : eax: c2bf7000 ebx: 430a7261 ecx: edx: c24f4780 : esi: f000fea5 edi: c24f4780 ebp: f000fea5 esp: c2bf7e38 : ds: 007b es: 007b fs: 00d8 gs: ss: 0068 : Process kswapd0 (pid: 243, ti=c2bf7000 task=c29ec030 task.ti=c2bf7000) : Stack: d6216868 002a d4f52670 0034 f000fea5 c01a34b6 :0246 c003fe08 ef082d98 ef082d4c ef082d4c c29f00c0 c003fdb8 c0198a8f : 0002ad02 ef082d4c c0145b21 c24f4780 000b c014a5e0 000e : Call Trace: : [journal_try_to_free_buffers+299/383] journal_try_to_free_buffers+0x12b/0x17f : [ext3_releasepage+0/114] ext3_releasepage+0x0/0x72 : [try_to_release_page+48/66] try_to_release_page+0x30/0x42 : [__invalidate_mapping_pages+116/231] __invalidate_mapping_pages+0x74/0xe7 : [invalidate_mapping_pages+15/17] invalidate_mapping_pages+0xf/0x11 : [shrink_icache_memory+219/445] shrink_icache_memory+0xdb/0x1bd : [shrink_slab+217/338] shrink_slab+0xd9/0x152 : [kswapd+729/1069] kswapd+0x2d9/0x42d : [autoremove_wake_function+0/53] autoremove_wake_function+0x0/0x35 : [kswapd+0/1069] kswapd+0x0/0x42d : [kthread+56/95] kthread+0x38/0x5f : [kthread+0/95] kthread+0x0/0x5f : [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 : === : Code: 89 e0 25 00 f0 ff ff ff 48 14 8b 40 08 a8 04 74 05 e8 a6 d6 0e 00 f3 90 89 e0 25 00 f0 ff ff ff 40 14 8b 03 a9 00 00 40 00 75 d5 0f ba 2b 16 19 c0 85 c0 75 ec 8b 46 04 85 c0 7f 30 c7 44 24 : EIP: [journal_put_journal_head+64/209] journal_put_journal_head+0x40/0xd1 SS:ESP 0068:c2bf7e38 : note: kswapd0[243] exited with preempt_count 2 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23.1-slab # Wed Nov 7 08:00:18 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_
Re: [PATCH] e2fsprogs: Handle rec_len correctly for 64KB blocksize
On Mon 12-11-07 09:58:23, Theodore Tso wrote: > On Mon, Nov 12, 2007 at 10:52:45AM +0100, Jan Kara wrote: > > > Did you test this patch before submitting it? > > > > Argh, stupid me. I've just tested that I didn't break anything for normal > > block size and thought that I cannot make mistake in such a simple thing > > ;). > > Could I ask you to perhaps include some 64k blocksize test cases that > would exercise the new codepaths? Fair enough, will do. > > > The only way to do this is to find all of the places that reference > > > rec_len, and do the check there. > > Yes.. Thanks for having look. > > One suggestion is that instead of just creating an conversion > function, and then doing a global search and replace, in some places > it might be better to declare an integer variable, and then assign > "rec_len = ext2fs_rec_len_from_disk(dirent->rec_len)". For example, > that would make ext2fs_process_dir_block() more readable, where > dirent->rec_len is used no less than eight times. OK, thanks for suggestion. > Thanks, and my apologies for not having time to review the patch until > now. At the moment things are a bit crazy since I am effectively > doing two jobs, since I am in transition between two assignments, and > me doing most of both of them at the moment. I should have > substantially more time after the new year begins. I see. I'll be patient then :) Honza -- Jan Kara <[EMAIL PROTECTED]> SUSE Labs, CR - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e2fsprogs: Handle rec_len correctly for 64KB blocksize
On Mon, Nov 12, 2007 at 10:52:45AM +0100, Jan Kara wrote: > > Did you test this patch before submitting it? > > Argh, stupid me. I've just tested that I didn't break anything for normal > block size and thought that I cannot make mistake in such a simple thing > ;). Could I ask you to perhaps include some 64k blocksize test cases that would exercise the new codepaths? > > The only way to do this is to find all of the places that reference > > rec_len, and do the check there. > Yes.. Thanks for having look. One suggestion is that instead of just creating an conversion function, and then doing a global search and replace, in some places it might be better to declare an integer variable, and then assign "rec_len = ext2fs_rec_len_from_disk(dirent->rec_len)". For example, that would make ext2fs_process_dir_block() more readable, where dirent->rec_len is used no less than eight times. Thanks, and my apologies for not having time to review the patch until now. At the moment things are a bit crazy since I am effectively doing two jobs, since I am in transition between two assignments, and me doing most of both of them at the moment. I should have substantially more time after the new year begins. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e2fsprogs: Handle rec_len correctly for 64KB blocksize
On Sat 10-11-07 19:37:03, Theodore Tso wrote: > On Wed, Nov 07, 2007 at 05:09:39PM +0100, Jan Kara wrote: > > > Subject: Support for 64KB blocksize in ext2-4 directories. > > > > When block size is 64KB, we have to take care that rec_len does not > > overflow. > > Kernel stores 0x in case 0x1 should be stored - perform appropriate > > conversion when reading from / writing to disk. > > NACK. You can't do the conversion in the reader/writer routines > because the fundamentally rec_len is only a 16 bit field. So when you > read a directory block where the rec_len field is encoded as 0x, > and you translate it to 0x1, when you assign it to > dirent->rec_len, the 0x1 gets chopped off and rec_len gets a value > of zero. Did you test this patch before submitting it? Argh, stupid me. I've just tested that I didn't break anything for normal block size and thought that I cannot make mistake in such a simple thing ;). > The only way to do this is to find all of the places that reference > rec_len, and do the check there. Yes.. Thanks for having look. Honza -- Jan Kara <[EMAIL PROTECTED]> SUSE Labs, CR - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
