[PATCH] [7/7] Remove incorrect BKL comments in ext4
Signed-off-by: Andi Kleen [EMAIL PROTECTED] --- fs/ext4/dir.c |2 +- fs/ext4/inode.c |1 - 2 files changed, 1 insertion(+), 2 deletions(-) Index: linux/fs/ext4/dir.c === --- linux.orig/fs/ext4/dir.c +++ linux/fs/ext4/dir.c @@ -46,7 +46,7 @@ const struct file_operations ext4_dir_op #ifdef CONFIG_COMPAT .compat_ioctl = ext4_compat_ioctl, #endif - .fsync = ext4_sync_file, /* BKL held */ + .fsync = ext4_sync_file, .release= ext4_release_dir, }; Index: linux/fs/ext4/inode.c === --- linux.orig/fs/ext4/inode.c +++ linux/fs/ext4/inode.c @@ -778,7 +778,6 @@ err_out: * * `handle' can be NULL if create == 0. * - * The BKL may not be held on entry here. Be sure to take it early. * return 0, # of blocks mapped or allocated. * return = 0, if plain lookup failed. * return 0, error case. - 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] [5/7] Remove incorrect comment refering to lock_kernel() from jbd/jbd2
None of the callers of this function does actually take the BKL as far as I can see. So remove the comment refering to the BKL. Signed-off-by: Andi Kleen [EMAIL PROTECTED] --- fs/jbd/recovery.c |2 +- fs/jbd2/recovery.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux/fs/jbd/recovery.c === --- linux.orig/fs/jbd/recovery.c +++ linux/fs/jbd/recovery.c @@ -354,7 +354,7 @@ static int do_one_pass(journal_t *journa struct buffer_head *obh; struct buffer_head *nbh; - cond_resched(); /* We're under lock_kernel() */ + cond_resched(); /* If we already know where to stop the log traversal, * check right now that we haven't gone past the end of Index: linux/fs/jbd2/recovery.c === --- linux.orig/fs/jbd2/recovery.c +++ linux/fs/jbd2/recovery.c @@ -364,7 +364,7 @@ static int do_one_pass(journal_t *journa struct buffer_head *obh; struct buffer_head *nbh; - cond_resched(); /* We're under lock_kernel() */ + cond_resched(); /* If we already know where to stop the log traversal, * check right now that we haven't gone past the end of - 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] [4/7] ext3: Remove incorrect BKL comment
There is no BKL held on entry in -fsync nor in the low level ext3_sync_file. Signed-off-by: Andi Kleen [EMAIL PROTECTED] --- fs/ext3/dir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/fs/ext3/dir.c === --- linux.orig/fs/ext3/dir.c +++ linux/fs/ext3/dir.c @@ -46,7 +46,7 @@ const struct file_operations ext3_dir_op #ifdef CONFIG_COMPAT .compat_ioctl = ext3_compat_ioctl, #endif - .fsync = ext3_sync_file, /* BKL held */ + .fsync = ext3_sync_file, .release= ext3_release_dir, }; - 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] [2/7] Remove incorrect BKL comment in ext2
No BKL used anywhere, so don't mention it. Signed-off-by: Andi Kleen [EMAIL PROTECTED] --- fs/ext2/inode.c |1 - 1 file changed, 1 deletion(-) Index: linux/fs/ext2/inode.c === --- linux.orig/fs/ext2/inode.c +++ linux/fs/ext2/inode.c @@ -569,7 +569,6 @@ static void ext2_splice_branch(struct in * * `handle' can be NULL if create == 0. * - * The BKL may not be held on entry here. Be sure to take it early. * return 0, # of blocks mapped or allocated. * return = 0, if plain lookup failed. * return 0, error case. - 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/7] Convert ext2 over to use unlocked_ioctl
I checked ext2_ioctl and could not find anything in there that would
need the BKL. So convert it over to use unlocked_ioctl
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
fs/ext2/dir.c |2 +-
fs/ext2/ext2.h |3 +--
fs/ext2/file.c |4 ++--
fs/ext2/ioctl.c | 12 +++-
4 files changed, 7 insertions(+), 14 deletions(-)
Index: linux/fs/ext2/dir.c
===
--- linux.orig/fs/ext2/dir.c
+++ linux/fs/ext2/dir.c
@@ -703,7 +703,7 @@ const struct file_operations ext2_dir_op
.llseek = generic_file_llseek,
.read = generic_read_dir,
.readdir= ext2_readdir,
- .ioctl = ext2_ioctl,
+ .unlocked_ioctl = ext2_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext2_compat_ioctl,
#endif
Index: linux/fs/ext2/ext2.h
===
--- linux.orig/fs/ext2/ext2.h
+++ linux/fs/ext2/ext2.h
@@ -139,8 +139,7 @@ int __ext2_write_begin(struct file *file
struct page **pagep, void **fsdata);
/* ioctl.c */
-extern int ext2_ioctl (struct inode *, struct file *, unsigned int,
- unsigned long);
+extern long ext2_ioctl(struct file *, unsigned int, unsigned long);
extern long ext2_compat_ioctl(struct file *, unsigned int, unsigned long);
/* namei.c */
Index: linux/fs/ext2/file.c
===
--- linux.orig/fs/ext2/file.c
+++ linux/fs/ext2/file.c
@@ -48,7 +48,7 @@ const struct file_operations ext2_file_o
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
- .ioctl = ext2_ioctl,
+ .unlocked_ioctl = ext2_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext2_compat_ioctl,
#endif
@@ -65,7 +65,7 @@ const struct file_operations ext2_xip_fi
.llseek = generic_file_llseek,
.read = xip_file_read,
.write = xip_file_write,
- .ioctl = ext2_ioctl,
+ .unlocked_ioctl = ext2_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext2_compat_ioctl,
#endif
Index: linux/fs/ext2/ioctl.c
===
--- linux.orig/fs/ext2/ioctl.c
+++ linux/fs/ext2/ioctl.c
@@ -17,9 +17,9 @@
#include asm/uaccess.h
-int ext2_ioctl (struct inode * inode, struct file * filp, unsigned int cmd,
- unsigned long arg)
+long ext2_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
+ struct inode *inode = filp-f_dentry-d_inode;
struct ext2_inode_info *ei = EXT2_I(inode);
unsigned int flags;
unsigned short rsv_window_size;
@@ -141,9 +141,6 @@ int ext2_ioctl (struct inode * inode, st
#ifdef CONFIG_COMPAT
long ext2_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
- struct inode *inode = file-f_path.dentry-d_inode;
- int ret;
-
/* These are just misnamed, they actually get/put from/to user an int */
switch (cmd) {
case EXT2_IOC32_GETFLAGS:
@@ -161,9 +158,6 @@ long ext2_compat_ioctl(struct file *file
default:
return -ENOIOCTLCMD;
}
- lock_kernel();
- ret = ext2_ioctl(inode, file, cmd, (unsigned long) compat_ptr(arg));
- unlock_kernel();
- return ret;
+ return ext2_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
}
#endif
-
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] [0/7] Drop BKL in ext[234] ioctls
Remove the BKL from the ext* ioctls. This is a slightly updated version of the ext[2-4] patches that hit linux-fsdevel earlier. -Andi - 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] [3/7] Convert ext3 to use unlocked_ioctl v2
I checked ext3_ioctl and it looked largely safe to not be used
without BKL. So convert it over to unlocked_ioctl.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
v1-v2: drop lock kernel for online growth. resize.c seems to do enough
locking
---
fs/ext3/dir.c |2 +-
fs/ext3/file.c |2 +-
fs/ext3/ioctl.c | 21 +++--
include/linux/ext3_fs.h |3 +--
4 files changed, 14 insertions(+), 14 deletions(-)
Index: linux/fs/ext3/dir.c
===
--- linux.orig/fs/ext3/dir.c
+++ linux/fs/ext3/dir.c
@@ -42,7 +42,7 @@ const struct file_operations ext3_dir_op
.llseek = generic_file_llseek,
.read = generic_read_dir,
.readdir= ext3_readdir, /* we take BKL. needed?*/
- .ioctl = ext3_ioctl, /* BKL held */
+ .unlocked_ioctl = ext3_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext3_compat_ioctl,
#endif
Index: linux/fs/ext3/file.c
===
--- linux.orig/fs/ext3/file.c
+++ linux/fs/ext3/file.c
@@ -112,7 +112,7 @@ const struct file_operations ext3_file_o
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = ext3_file_write,
- .ioctl = ext3_ioctl,
+ .unlocked_ioctl = ext3_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext3_compat_ioctl,
#endif
Index: linux/fs/ext3/ioctl.c
===
--- linux.orig/fs/ext3/ioctl.c
+++ linux/fs/ext3/ioctl.c
@@ -17,9 +17,9 @@
#include linux/smp_lock.h
#include asm/uaccess.h
-int ext3_ioctl (struct inode * inode, struct file * filp, unsigned int cmd,
- unsigned long arg)
+long ext3_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
+ struct inode *inode = filp-f_dentry-d_inode;
struct ext3_inode_info *ei = EXT3_I(inode);
unsigned int flags;
unsigned short rsv_window_size;
@@ -263,9 +270,6 @@ flags_err:
#ifdef CONFIG_COMPAT
long ext3_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
- struct inode *inode = file-f_path.dentry-d_inode;
- int ret;
-
/* These are just misnamed, they actually get/put from/to user an int */
switch (cmd) {
case EXT3_IOC32_GETFLAGS:
@@ -305,9 +309,6 @@ long ext3_compat_ioctl(struct file *file
default:
return -ENOIOCTLCMD;
}
- lock_kernel();
- ret = ext3_ioctl(inode, file, cmd, (unsigned long) compat_ptr(arg));
- unlock_kernel();
- return ret;
+ return ext3_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
}
#endif
Index: linux/include/linux/ext3_fs.h
===
--- linux.orig/include/linux/ext3_fs.h
+++ linux/include/linux/ext3_fs.h
@@ -838,8 +838,7 @@ extern void ext3_get_inode_flags(struct
extern void ext3_set_aops(struct inode *inode);
/* ioctl.c */
-extern int ext3_ioctl (struct inode *, struct file *, unsigned int,
- unsigned long);
+extern long ext3_ioctl(struct file *, unsigned int, unsigned long);
extern long ext3_compat_ioctl (struct file *, unsigned int, unsigned long);
/* namei.c */
-
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] [6/7] Convert ext4 to use unlocked_ioctl v2
I checked ext4_ioctl and it looked largely safe to not be used
without BKL. So convert it over to unlocked_ioctl.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
v1-v2: drop BKL for online grow. resize.c seems to do enough locking
---
fs/ext4/dir.c |2 +-
fs/ext4/file.c |2 +-
fs/ext4/ioctl.c | 20 +++-
include/linux/ext4_fs.h |3 +--
4 files changed, 14 insertions(+), 13 deletions(-)
Index: linux/fs/ext4/dir.c
===
--- linux.orig/fs/ext4/dir.c
+++ linux/fs/ext4/dir.c
@@ -42,7 +42,7 @@ const struct file_operations ext4_dir_op
.llseek = generic_file_llseek,
.read = generic_read_dir,
.readdir= ext4_readdir, /* we take BKL. needed?*/
- .ioctl = ext4_ioctl, /* BKL held */
+ .unlocked_ioctl = ext4_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext4_compat_ioctl,
#endif
Index: linux/fs/ext4/file.c
===
--- linux.orig/fs/ext4/file.c
+++ linux/fs/ext4/file.c
@@ -112,7 +112,7 @@ const struct file_operations ext4_file_o
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = ext4_file_write,
- .ioctl = ext4_ioctl,
+ .unlocked_ioctl = ext4_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ext4_compat_ioctl,
#endif
Index: linux/fs/ext4/ioctl.c
===
--- linux.orig/fs/ext4/ioctl.c
+++ linux/fs/ext4/ioctl.c
@@ -17,9 +17,9 @@
#include linux/smp_lock.h
#include asm/uaccess.h
-int ext4_ioctl (struct inode * inode, struct file * filp, unsigned int cmd,
- unsigned long arg)
+long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
+ struct inode *inode = filp-f_dentry-d_inode;
struct ext4_inode_info *ei = EXT4_I(inode);
unsigned int flags;
unsigned short rsv_window_size;
@@ -262,9 +270,6 @@ flags_err:
#ifdef CONFIG_COMPAT
long ext4_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
- struct inode *inode = file-f_path.dentry-d_inode;
- int ret;
-
/* These are just misnamed, they actually get/put from/to user an int */
switch (cmd) {
case EXT4_IOC32_GETFLAGS:
@@ -304,9 +309,6 @@ long ext4_compat_ioctl(struct file *file
default:
return -ENOIOCTLCMD;
}
- lock_kernel();
- ret = ext4_ioctl(inode, file, cmd, (unsigned long) compat_ptr(arg));
- unlock_kernel();
- return ret;
+ return ext4_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
}
#endif
Index: linux/include/linux/ext4_fs.h
===
--- linux.orig/include/linux/ext4_fs.h
+++ linux/include/linux/ext4_fs.h
@@ -939,8 +939,7 @@ extern int ext4_block_truncate_page(hand
struct address_space *mapping, loff_t from);
/* ioctl.c */
-extern int ext4_ioctl (struct inode *, struct file *, unsigned int,
- unsigned long);
+extern long ext4_ioctl(struct file *, unsigned int, unsigned long);
extern long ext4_compat_ioctl (struct file *, unsigned int, unsigned long);
/* namei.c */
-
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] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl
Theodore Tso [EMAIL PROTECTED] writes: Coding-style only changes tends to screw up our ability to merge pending patches, but I'll take care of it, thanks. Exactly. And looking at the patch the old code was already perfectly readable anyways. Benefit about zero. I also don't see how you can take care of patch conflicts caused by this for patches not yet in your tree but still in development somewhere else. IMHO any coding style cleanup should only done on code that changes anyways, but not on other code. The recent flurry of cleanup code patches on l-k causes far more problems than it solves. I'm not even sure why people do this? Just because it is en vogue recently? If they want to contribute in simple ways to the Linux kernel I'm sure actually really useful things can be found that they can change. -Andi - 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] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl
Personally I find it annoying, but I'm willing to live with the cleanup patches. I don't think they add anything, though. Maybe I The problem I see is that if someone has a more involved outstanding patch series against the code that is being cleaned up (and more complicated features tend to require some time to stabilize so just merge early is not always the solution) then it is a serious mess to readapt a patch series to the cleanups. Yes it can be all done but it wastes time that would be more constructively used e.g. for better testing. Now if some area is changed anyways then they're usually ok because all outstanding patches will need to be adapted anyways. So I guess a useful rule for cleanup patches would be only if that code changed recently The recent flurry of cleanup code patches on l-k causes far more problems than it solves. I'm not even sure why people do this? Just because it is en vogue recently? I don't know, because people want to be able to say that they've contributed fixes to the Linux kernel? My pet theory is that it is similar to the unsubscribe me cascade effect you sometimes see on mailing lists. One person sends a unsubscribe me to everybody and then suddenly a lot of people think that is the right way to unsubscribe and reply with lots of unsubscribe me too. So one person sends a cleanup and it gets accepted and suddenly other people realize it is very easy to do these cleanups (not realizing the hidden costs they have) and then they go on... I thought we had the janitor project to steer these people into more useful directions, but apparently that is not well known enough anymore. Perhaps it just needs to be more regularly announced? Although I must admit I am not 100% happy with kernel-janitors either -- e.g. a few times I sent suggestions about easy things someone could do to that list, but never heard anything back. Anyways there are lots of ways to do trivial cleanups in a useful way and if people want to do this perhaps they should just ask on linux-kernel and people suggest something? My hope here is of course that these trivial changes are primarily used as a way to get the feet wet to understand the procedures for contribuing larger not quite as trivial changes -Andi P.S.: Mathieu, this is not against you personally; you just happened to be a convenient example of a larger problem in this case. Sorry. - 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] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl
On Fri, Jan 04, 2008 at 09:03:53PM +0100, Paolo Ciarrocchi wrote: On Jan 4, 2008 8:41 PM, Andi Kleen [EMAIL PROTECTED] wrote: [...] I don't know, because people want to be able to say that they've contributed fixes to the Linux kernel? My pet theory is that it is similar to the unsubscribe me cascade effect you sometimes see on mailing lists. One person sends a unsubscribe me to everybody and then suddenly a lot of people think that is the right way to unsubscribe and reply with lots of unsubscribe me too. So one person sends a cleanup and it gets accepted and suddenly other people realize it is very easy to do these cleanups (not realizing the hidden costs they have) and then they go on... Since I'm one of those people that sent Codying style fixes patches I give my contribution to this discussion as well. I think that _one_ of the reasons that made a few people sent this kind of patches to the list is because checkpatch.pl is far better then any other kerneljanitor scripts/easy task and _seems_ to be an easy way to start understanding the code, creation of patches and process in general. The problem is that it has large hidden costs as pointed out. So while it might be easy for you it's not a cheap operation for the whole development process. I thought we had the janitor project to steer these people into more useful directions, but apparently that is not well known enough anymore. Perhaps it just needs to be more regularly announced? Although I must admit I am not 100% happy with kernel-janitors either -- e.g. a few times I sent suggestions about easy things someone could do to that list, but never heard anything back. Anyways there are lots of ways to do trivial cleanups in a useful way and if people want to do this perhaps they should just ask on linux-kernel and people suggest something? Yes please do that. Even if fixing errors reported by checkpatch.pl still sounds like a useful way to spent a couple of hours. Maybe our mistake was to send the patches to lkml instead of to [EMAIL PROTECTED] or to kerneljanitors? No, they would have ended in tree too eventually and caused the same problem. How about if you're looking for simple work for a few hours you just send an email to l-k and ask if someone has an idea for something? I'm sure you'll get suggestions. Probably more than you can take. e.g. from the top of my hat what would be useful: - Go through Documentation/* files and check if the options etc. described in there are still in the code That will actually require you to find code in the source tree and understand it at least a little bit which are both very useful skills in general. - Or check for kerneldoc comments that do not appear in the kerneldoc output (because the files are missing in the DocBook templates) - Or build the kernel and check for any deprecated warnings and fix them [perhaps not 100% trivial, but should be doable by studying other code a bit -- i expect that people who attempt to write such patches have at least some knowledge of programming and C so that should be possible] I mean, I now understand the rationales behind your complaints but I don't think it's good idea to discourage people willing to perform easy task. They just need guidance in order to be useful. Yes, the best way to get guidance is to ask. -Andi - 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: Enabling h-trees too early?
Theodore Tso [EMAIL PROTECTED] writes: Certainly one of the things that we could consider is for small directories to do an in-memory sort of all of the directory entries at opendir() time, and keeping that list until it is closed. We can't do this for really big directories, but we could easily do it for directories under 32k or 64k. I assume you mean sort by inode, because sort by htree key would be as bad as htrees. But wouldn't that break parallel readdir for a directory that just grows from 32/64K to over it? e.g. if the sort moves already read entries to after the cursor readdir would return some entries twice. I suspect you would need to keep it always sorted after that no matter how big it gets. So the 32/64k boundary seems useless and you would need a sorted potentially partial in memory rbtree anyways. -Andi - 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: Random corruption test for e2fsck
On Wed, Jul 11, 2007 at 11:19:38PM -0600, Andreas Dilger wrote: On Jul 11, 2007 17:20 +0200, Andi Kleen wrote: If you use a normal pseudo random number generator and print the seed (e.g. create from the time) initially the image can be easily recreated later without shipping it around. /dev/urandom is not really needed for this since you don't need cryptographic strength randomness. Besides urandom data is precious and it's a pity to use it up needlessly. bash has $RANDOM built in for this purpose. Except it is a lot more efficient and easy to do Ah you chose to only address one sentence in my reply. I thought only Linus liked to to do that. If you're worried about efficiency it's trivial to write a C program that generates bulk pseudo random numbers using random(3) dd if=/dev/urandom bs=1k ... than to spin in a loop getting 16-bit random numbers from bash. We would also be at the mercy of the shell being identical on the user and debugger's systems. With /dev/urandom you have the guarantee you'll never ever reproduce it again. Andrea A. used to rant about people who use srand(time(NULL)) in benchmarks and it's sad these mistakes get repeated again and again. -Andi - 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: [RFC][PATCH] Multiple mount protection
Kalpak Shah [EMAIL PROTECTED] writes: Hi, There have been reported instances of a filesystem having been mounted at 2 places at the same time causing a lot of damage to the filesystem. This patch reserves superblock fields and an INCOMPAT flag for adding multiple mount protection(MMP) support within the ext4 filesystem itself. The superblock will have a block number (s_mmp_block) which will hold a MMP structure which has a sequence number which will be periodically updated every 5 seconds by a mounted filesystem. Whenever a filesystem will be mounted it will wait for s_mmp_interval seconds to make sure that the MMP sequence does not change. To further make sure, we write a random sequence number into the MMP block and wait for another s_mmp_interval secs. If the sequence no. doesn't change then the mount will succeed. In case of failure, the nodename, bdevname and the time at which the MMP block was last updated will be displaye d. tune2fs can be used to set s_mmp_interval as desired. That will make laptop users very unhappy if you spin up their disks every 5 seconds. And even on other systems it might reduce the MTBF if you write the super block much more often than before. It might be better to set it up in some way to only increase that number when the super block is written for some other reason anyways. -Andi - 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: Directories 2GB
Steve Lord [EMAIL PROTECTED] writes: David Chinner wrote: On Tue, Oct 10, 2006 at 10:19:04AM +0100, Christoph Hellwig wrote: On Mon, Oct 09, 2006 at 09:15:28PM -0500, Steve Lord wrote: Hi Dave, My recollection is that it used to default to on, it was disabled because it needs to map the buffer into a single contiguous chunk of kernel memory. This was placing a lot of pressure on the memory remapping code, so we made it not default to on as reworking the code to deal with non contig memory was looking like a major effort. Exactly. The code works but tends to go OOM pretty fast at least when the dir blocksize code is bigger than the page size. I should give the code a spin on my ppc box with 64k pages if it works better there. The pagebuf code doesn't use high-order allocations anymore; it uses scatter lists and remapping to allow physically discontiguous pages in a multi-page buffer. That is, the pages are sourced via find_or_create_page() from the address space of the backing device, and then mapped via vmap() to provide a virtually contigous mapping of the multi-page buffer. So I don't think this problem exists anymore... I was not referring to high order allocations here, but the overhead of doing address space remapping every time a directory is accessed. # grep -i vmalloc /proc/meminfo VmallocTotal: 34359738367 kB At least on 64bit systems it would be reasonable to keep a large number of directories mapped this way over a longer time. vmap() space is cheap there. -Andi - 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
