[PATCH] Ext3 online resizing locking issue
This simple patch provides a fix for a locking issue found in the online
resizing code. The problem actually happened while trying to resize the
filesystem trough the resize=xxx option in a remount.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
diff -up linux-2.6.13-rc6-orig/fs/ext3/ioctl.c linux/fs/ext3/ioctl.c
--- linux-2.6.13-rc6-orig/fs/ext3/ioctl.c 2005-08-24 17:48:22.0
-0300
+++ linux/fs/ext3/ioctl.c 2005-08-24 15:12:48.0 -0300
@@ -206,7 +206,9 @@ flags_err:
if (get_user(n_blocks_count, (__u32 __user *)arg))
return -EFAULT;
+ lock_super(sb);
err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count);
+ unlock_super(sb);
journal_lock_updates(EXT3_SB(sb)->s_journal);
journal_flush(EXT3_SB(sb)->s_journal);
journal_unlock_updates(EXT3_SB(sb)->s_journal);
Only in linux/fs/ext3: patch-mnt_resize
diff -up linux-2.6.13-rc6-orig/fs/ext3/resize.c linux/fs/ext3/resize.c
--- linux-2.6.13-rc6-orig/fs/ext3/resize.c 2005-08-24 17:48:22.0
-0300
+++ linux/fs/ext3/resize.c 2005-08-24 15:15:28.0 -0300
@@ -884,7 +884,9 @@ exit_put:
/* Extend the filesystem to the new number of blocks specified. This entry
* point is only used to extend the current filesystem to the end of the last
* existing group. It can be accessed via ioctl, or by "remount,resize="
- * for emergencies (because it has no dependencies on reserved blocks).
+ * for emergencies (because it has no dependencies on reserved blocks).
+ *
+ * It should be called with sb->s_lock held
*
* If we _really_ wanted, we could use default values to call ext3_group_add()
* allow the "remount" trick to work for arbitrary resizing, assuming enough
@@ -959,7 +961,6 @@ int ext3_group_extend(struct super_block
goto exit_put;
}
- lock_super(sb);
if (o_blocks_count != le32_to_cpu(es->s_blocks_count)) {
ext3_warning(sb, __FUNCTION__,
"multiple resizers run on filesystem!\n");
@@ -978,7 +979,6 @@ int ext3_group_extend(struct super_block
es->s_blocks_count = cpu_to_le32(o_blocks_count + add);
ext3_journal_dirty_metadata(handle, EXT3_SB(sb)->s_sbh);
sb->s_dirt = 1;
- unlock_super(sb);
ext3_debug("freeing blocks %ld through %ld\n", o_blocks_count,
o_blocks_count + add);
ext3_free_blocks_sb(handle, sb, o_blocks_count, add, &freed_blocks);
diff -up linux-2.6.13-rc6-orig/fs/ext3/super.c linux/fs/ext3/super.c
--- linux-2.6.13-rc6-orig/fs/ext3/super.c 2005-08-24 17:48:22.0
-0300
+++ linux/fs/ext3/super.c 2005-08-24 15:13:16.0 -0300
@@ -639,8 +639,8 @@ static match_table_t tokens = {
{Opt_quota, "quota"},
{Opt_quota, "usrquota"},
{Opt_barrier, "barrier=%u"},
+ {Opt_resize, "resize=%u"},
{Opt_err, NULL},
- {Opt_resize, "resize"},
};
static unsigned long get_sb_block(void **data)
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [EMAIL PROTECTED]: Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs]
On Wed, Aug 24, 2005 at 09:18:35AM +0200, Christoph Hellwig wrote: > - oracore workarounds must go away These are not part of the linus-ward submission. > - magic symlinks that pollute the posix filename namespace must go >away We're still trying to come up with a way to solve the problem without magic symlinks. Suggestions still welcome. > - vma-walking locking must move to common code (zab is working on that >afaik) The vma-walking will go away, replaced by another mmap scheme entirely. However, that's three or four months away. The current code is merely a stopgap for now. Many folks have an interest in having a cluster filesystem in mainline. This seems like an issue that can be resolved later, not a big blocker. That is, it would be worth more to people to have it in mainline for the next four months, knowing this will get fixed, than keeping it out of mainline for four months over this feature. > - the buffered aio mess needs sorting out. imho the best thing was Well, that's a mainline problem. Yes, we should all work towards improving mainline. But again I'm not sure others are served keeping OCFS2 out over this. > - there's still some procfs abuse Specifics of what is abuse vs OK would be interesting. > That's just the off my head things, the oracle people actually asked > me to wait with a review until they've cleared their TODO lists, I'll > do a real review once I'll get some time. There are some sizeable things on this "top of the head" list already. I'd like to find a nice balance between "goes to mainline now" and "must be a perfect piece of software before it goes in." No software will ever be perfect. Joel -- "For every complex problem there exists a solution that is brief, concise, and totally wrong." -Unknown http://www.jlbec.org/ [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC][PATCH] VFS: update documentation (take #2)
Hi,
This is my second go at giving you my comments. The first time the email
got lost due to a connection crash. )-: Anyway, its great to see this
updated!
On Wed, 24 Aug 2005, Pekka Enberg wrote:
> This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
> to life. Thanks to Carsten Otte for the description on get_xip_page().
>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
>
> vfs.txt | 382
>
> 1 file changed, 291 insertions(+), 91 deletions(-)
>
> Index: 2.6-mm/Documentation/filesystems/vfs.txt
> ===
> --- 2.6-mm.orig/Documentation/filesystems/vfs.txt
> +++ 2.6-mm/Documentation/filesystems/vfs.txt
> @@ -1,10 +1,9 @@
> -/* -*- auto-fill -*-
> */
>
> Overview of the Virtual File System
>
> - Richard Gooch <[EMAIL PROTECTED]>
> + Original author: Richard Gooch <[EMAIL PROTECTED]>
>
> - 5-JUL-1999
> + Last updated on August 24, 2005
>
>
> Conventions used in this document
>
> @@ -15,9 +14,6 @@ right-hand side of the section title. Ea
> "" at the right-hand side. These strings are meant to make
> it easier to search through the document.
>
> -NOTE that the master copy of this document is available online at:
> -http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
> -
>
> What is it?
>
> ===
> @@ -26,7 +22,7 @@ The Virtual File System (otherwise known
> Switch) is the software layer in the kernel that provides the
> filesystem interface to userspace programs. It also provides an
> abstraction within the kernel which allows different filesystem
> -implementations to co-exist.
> +implementations to coexist.
>
>
> A Quick Look At How It Works
>
> @@ -77,7 +73,7 @@ back to userspace.
>
> Opening a file requires another operation: allocation of a file
> structure (this is the kernel-side implementation of file
> -descriptors). The freshly allocated file structure is initialised with
> +descriptors). The freshly allocated file structure is initialized with
> a pointer to the dentry and a set of file operation member functions.
> These are taken from the inode data. The open() file method is then
> called so the specific filesystem implementation can do it's work. You
> @@ -126,14 +122,18 @@ It's now time to look at things in more
> struct file_system_type
>
> ===
>
> -This describes the filesystem. As of kernel 2.1.99, the following
> +This describes the filesystem. As of kernel 2.6.13, the following
> members are defined:
>
> struct file_system_type {
> const char *name;
> int fs_flags;
> - struct super_block *(*read_super) (struct super_block *, void *, int);
> - struct file_system_type * next;
> +struct super_block *(*get_sb) (struct file_system_type *, int,
> + const char *, void *);
> +void (*kill_sb) (struct super_block *);
> +struct module *owner;
> +struct file_system_type * next;
> +struct list_head fs_supers;
> };
>
>name: the name of the filesystem type, such as "ext2", "iso9660",
> @@ -141,51 +141,96 @@ struct file_system_type {
>
>fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
>
> - read_super: the method to call when a new instance of this
> + get_sb: the method to call when a new instance of this
> filesystem should be mounted
>
> - next: for internal VFS use: you should initialise this to NULL
> + kill_sb: the method to call when an instance of this filesystem
> + should be unmounted
> +
> + owner: for internal VFS use: you should initialize this to NULL
>
> -The read_super() method has the following arguments:
> + next: for internal VFS use: you should initialize this to NULL
> +
> +The get_sb() method has the following arguments:
>
>struct super_block *sb: the superblock structure. This is partially
> - initialised by the VFS and the rest must be initialised by the
> - read_super() method
> + initialized by the VFS and the rest must be initialized by the
> + get_sb() method
> +
> + int flags: mount flags
> +
> + const char *dev_name: the device name we are mounting.
>
>void *data: arbitrary mount options, usually comes as an ASCII
> string
>
>int silent: whether or not to be silent on error
>
> -The read_super() method must determine if the block device specified
> +The get_sb() method must determine if the block device specified
> in the superblock contains a filesystem of the type the method
> supports. On success the method returns the superblock point
Re: [RFC][PATCH] VFS: update documentation (take #2)
on den 24.08.2005 Klokka 21:36 (+0300) skreiv Pekka Enberg:
>
> struct file_system_type {
> const char *name;
> int fs_flags;
> - struct super_block *(*read_super) (struct super_block *, void *, int);
> - struct file_system_type * next;
> +struct super_block *(*get_sb) (struct file_system_type *, int,
> + const char *, void *);
> +void (*kill_sb) (struct super_block *);
> +struct module *owner;
> +struct file_system_type * next;
> +struct list_head fs_supers;
> };
>
>name: the name of the filesystem type, such as "ext2", "iso9660",
> @@ -141,51 +141,96 @@ struct file_system_type {
>
>fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
>
> - read_super: the method to call when a new instance of this
> + get_sb: the method to call when a new instance of this
> filesystem should be mounted
>
> - next: for internal VFS use: you should initialise this to NULL
> + kill_sb: the method to call when an instance of this filesystem
> + should be unmounted
> +
> + owner: for internal VFS use: you should initialize this to NULL
owner should be set to THIS_MODULE in most cases...
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] VFS: update documentation (take #2)
Hi,
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
to life. Thanks to Carsten Otte for the description on get_xip_page().
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
vfs.txt | 382
1 file changed, 291 insertions(+), 91 deletions(-)
Index: 2.6-mm/Documentation/filesystems/vfs.txt
===
--- 2.6-mm.orig/Documentation/filesystems/vfs.txt
+++ 2.6-mm/Documentation/filesystems/vfs.txt
@@ -1,10 +1,9 @@
-/* -*- auto-fill -*- */
Overview of the Virtual File System
- Richard Gooch <[EMAIL PROTECTED]>
+ Original author: Richard Gooch <[EMAIL PROTECTED]>
- 5-JUL-1999
+ Last updated on August 24, 2005
Conventions used in this document
@@ -15,9 +14,6 @@ right-hand side of the section title. Ea
"" at the right-hand side. These strings are meant to make
it easier to search through the document.
-NOTE that the master copy of this document is available online at:
-http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
-
What is it?
===
@@ -26,7 +22,7 @@ The Virtual File System (otherwise known
Switch) is the software layer in the kernel that provides the
filesystem interface to userspace programs. It also provides an
abstraction within the kernel which allows different filesystem
-implementations to co-exist.
+implementations to coexist.
A Quick Look At How It Works
@@ -77,7 +73,7 @@ back to userspace.
Opening a file requires another operation: allocation of a file
structure (this is the kernel-side implementation of file
-descriptors). The freshly allocated file structure is initialised with
+descriptors). The freshly allocated file structure is initialized with
a pointer to the dentry and a set of file operation member functions.
These are taken from the inode data. The open() file method is then
called so the specific filesystem implementation can do it's work. You
@@ -126,14 +122,18 @@ It's now time to look at things in more
struct file_system_type
===
-This describes the filesystem. As of kernel 2.1.99, the following
+This describes the filesystem. As of kernel 2.6.13, the following
members are defined:
struct file_system_type {
const char *name;
int fs_flags;
- struct super_block *(*read_super) (struct super_block *, void *, int);
- struct file_system_type * next;
+struct super_block *(*get_sb) (struct file_system_type *, int,
+ const char *, void *);
+void (*kill_sb) (struct super_block *);
+struct module *owner;
+struct file_system_type * next;
+struct list_head fs_supers;
};
name: the name of the filesystem type, such as "ext2", "iso9660",
@@ -141,51 +141,96 @@ struct file_system_type {
fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
- read_super: the method to call when a new instance of this
+ get_sb: the method to call when a new instance of this
filesystem should be mounted
- next: for internal VFS use: you should initialise this to NULL
+ kill_sb: the method to call when an instance of this filesystem
+ should be unmounted
+
+ owner: for internal VFS use: you should initialize this to NULL
-The read_super() method has the following arguments:
+ next: for internal VFS use: you should initialize this to NULL
+
+The get_sb() method has the following arguments:
struct super_block *sb: the superblock structure. This is partially
- initialised by the VFS and the rest must be initialised by the
- read_super() method
+ initialized by the VFS and the rest must be initialized by the
+ get_sb() method
+
+ int flags: mount flags
+
+ const char *dev_name: the device name we are mounting.
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
-The read_super() method must determine if the block device specified
+The get_sb() method must determine if the block device specified
in the superblock contains a filesystem of the type the method
supports. On success the method returns the superblock pointer, on
failure it returns NULL.
The most interesting member of the superblock structure that the
-read_super() method fills in is the "s_op" field. This is a pointer to
+get_sb() method fills in is the "s_op" field. This is a pointer to
a "struct super_operations" which describes the next level of the
filesystem implementation.
+Usually, a filesystem uses generic one of the generic get_sb()
+implementa
Re: [EMAIL PROTECTED]: Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs]
> > > BTW, from where I sit, ocfs2 is "on hold" due to some additional work > > > which > > > hch identified when I was on vacation and not paying much attention. vma > > > walk, perhaps? > > > > I don't know of anything that should put it "on hold". Copying > > Mark on this. Mark? > > (cc hch) > > On 10 Aug Christoph told me "While OCFS is evolving really nicely there's a > bunch of major things that need to be sorted out". > > Christoph, could you please itemise these things? Major items known: - oracore workarounds must go away - magic symlinks that pollute the posix filename namespace must go away - vma-walking locking must move to common code (zab is working on that afaik) - the buffered aio mess needs sorting out. imho the best thing was to just drop that code from ocfs for now and let oracle work with bcrl and suparna to make sure their buffered aio code works nicely with ocfs and/or picks up some of their ideas - there's still some procfs abuse That's just the off my head things, the oracle people actually asked me to wait with a review until they've cleared their TODO lists, I'll do a real review once I'll get some time. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
