Fw: ext3 dir_index causes an error
Ted is dir_index maintainer ;)
That's a nice-looking bug report, btw. Thanks.
Begin forwarded message:
Date: Fri, 01 Jun 2007 13:01:07 +0900
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: ext3 dir_index causes an error
Hello,
First of all, I really appricate your great works.
Now I've found a problem around dir_index feature.
Here is a report following linux/REPORTING-BUGS.
[1.] One line summary of the problem:
ext3 dir_index causes an error
[2.] Full description of the problem/report:
This is my local test program to reproduce this problem. The
readdir1.c calls creat(2), opendir(3) and readdir(3). And the shell
script execute it repeatedly with a brand-new ext3fs image on a
loopback device.
When the script adds '-O dir_index' to mkfs, some errors appear.
On a system with linux-2.6.21.3, ext3fs produces these error message,
and the filesystem seems to be corrupted.
--
kjournald starting. Commit interval 5 seconds
EXT3 FS on loop0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
:::
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs error (device loop0): htree_dirblock_to_tree: bad entry in directory
#2: rec_len is too small for name_len - offset=6924, inode=26, rec_len=244,
name_len=249
EXT3-fs error (device loop0): htree_dirblock_to_tree: bad entry in directory
#2: rec_len is too small for name_len - offset=6924, inode=26, rec_len=244,
name_len=249
EXT3-fs error (device loop0): htree_dirblock_to_tree: bad entry in directory
#2: rec_len is too small for name_len - offset=6924, inode=26, rec_len=244,
name_len=249
kjournald starting. Commit interval 5 seconds
:::
--
On the other system with linux-2.6.18 (debian etch kernel), the same
error appears.
When the script adds '-O ^dir_index' to mkfs, the problem never appears.
It is not everytime that these errors appear. So the shell script
executes the readdir1 test program repeatedly.
Recently I upgraded my debian system from version 3.1 'sarge' to 4.0
'etch'. The debian etch sets the dir_index feature by default. So I
found this problem.
[3.] Keywords (i.e., modules, networking, kernel):
ext3 dir_index
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
[4.2.] Kernel .config file:
[5.] Most recent kernel version which did not have the bug:
[6.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
[7.] A small shell script or example program which triggers the
problem (if possible)
(readdir1.c)
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
void fin(char *s)
{
perror(s);
exit(1);
}
void msg(int found, char *fname)
{
printf("%s%s found\n", fname, found?"":" not");
}
int
main(int argc, char *argv[])
{
DIR *dp;
struct dirent *de;
int err, found, i;
char a[250];
err = chdir(argv[1]);
if (err)
fin("chdir");
memset(a, 'a', sizeof(a)-1);
a[sizeof(a)-1] = 0;
for (i = 0; i < 16+1; i++) {
a[0]++;
err = creat(a, 0644);
if (err < 0)
fin("creat");
err = creat(argv[2], 0644);
if (err < 0)
fin("creat");
}
#if 0
err = unlink(argv[2]);
if (err && errno != ENOENT)
fin("unlink");
#endif
dp = opendir(".");
if (!dp)
fin("opendir");
de = readdir(dp);
if (!de)
fin("1st readdir");
assert(strcmp(argv[2], de->d_name));
#if 0
argv[2][0]++;
err = creat(argv[2], 0644);
if (err < 0)
fin("creat");
argv[2][0]--;
#endif
err = creat(argv[2], 0644);
if (err < 0)
fin("creat");
#if 0
err = unlink(argv[2]);
if (err && errno != ENOENT)
fin("unlink");
#endif
found = 0;
while ((de = readdir(dp)) && !found)
found = !strcmp(argv[2], de->d_name);
msg(found, argv[2]);
found = 0;
rewinddir(dp);
while ((de = readdir(dp)) && !found)
found = !strcmp(argv[2], de->d_name);
msg(found, argv[2]);
closedir(dp);
dp = opendir(".");
if (!dp)
fin("opendir");
found = 0;
while ((de = readdir(dp)) && !found)
found = !strcmp(argv[2], de->d_name);
msg(found, argv[2]);
return 0;
}
--
#!/bin/sh
img=rw.img
dir=rw
set -e
make /tmp/readdir1
cd /dev/shm
dd if=/dev/zero of=$img bs=1k count=4k 2> /dev/null
mkdir -p $dir
ulimit -c un
Re: [RFC] store RAID stride in superblock
On May 31, 2007 17:33 -0400, Theodore Tso wrote: > Oops, I just pushed a set of bugfixes to Linux that included the > superblock field reservations. Oh well. > What is in the e2fsprogs hg repository ... is: > > .. > __u16 s_raid_stride; /* RAID stride */ > __u16 s_mmp_interval; /* # seconds to wait in MMP checking */ > __u64 s_mmp_block;/* Block for multi-mount protection */ > __u32 s_raid_stripe_width;/* blocks on all data disks (N*stride)*/ > __u32 s_reserved[163];/* Padding to the end of the block */ > }; We're updating our patches to be based on the new HG code. > One question which does come to mind; is there any reason why we might > want to know the RAID level and/or the number of disks (as opposed to > just the stripe width)? Not so far. The raid_stride is for bitmap placement (and could also be used for alignment of random IOs to avoid making 2 disks busy when 1 would do). The raid_stripe_width is the amount that delalloc+mballoc will use for allocations+writes to avoid read-modify-write of RAID stripes. It doesn't really matter what the RAID level is. > And has anyone investigated where there are > magic ioctl's or libdevmapper APi's so we can get the RAID parameters > automatically? If so, patches so that mke2fs can get the information > automatically (as opposed to forcing the user to have to specify lots > of annoying options) would be most welcome For now we will specify this via mke2fs or tune2fs for existing filesystems. The XFS folks mentioned they have a library to extract this info for linux devices (e.g. DM, MD, etc), but of course that still won't work for e.g. external RAID devices. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - 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] store RAID stride in superblock
Theodore Tso wrote: And has anyone investigated where there are magic ioctl's or libdevmapper APi's so we can get the RAID parameters automatically? If so, patches so that mke2fs can get the information automatically (as opposed to forcing the user to have to specify lots of annoying options) would be most welcome xfsprogs has a libdisk which does this for evms, lvm, md, dm, and xvm(!) see for example md_get_subvol_stripe() in xfsprogs. -Eric - 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] store RAID stride in superblock
On Thu, May 31, 2007 at 02:19:02PM -0600, Andreas Dilger wrote: > Ah, we've been doing it the other way around here. It makes sense to keep > the s_raid_stripe_width fields together. I think this code is preliminary > enough that nobody has actually started using it yet. Can you please post > what the end of ext2_super_block looks like (whether you decide to reorder > the fields or not). Oops, I just pushed a set of bugfixes to Linux that included the superblock field reservations. I was going back and forth about whether to keep them together, or whether to keep the extra u16 s_pad and then have to reserve another u16 field plus another u16 field for MMP seconds field. Since you guys had been talking about the MMP code for longer period of time (I think you first made the proposal a few months ago), I had assumed it had precedence (and had possibly already been in use at some customer somewhere), so I used Kalpak's original MMP superblock field reservations. I don't think it's worth changing at this point. (If no one is using it yet, it won't be too hard to switch around so we're all doing the same thing. :-) What is in the e2fsprogs hg repository as well as the for_linus branch of ext4.git is: .. __u16 s_raid_stride; /* RAID stride */ __u16 s_mmp_interval; /* # seconds to wait in MMP checking */ __u64 s_mmp_block;/* Block for multi-mount protection */ __u32 s_raid_stripe_width;/* blocks on all data disks (N*stride)*/ __u32 s_reserved[163];/* Padding to the end of the block */ }; One question which does come to mind; is there any reason why we might want to know the RAID level and/or the number of disks (as opposed to just the stripe width)? And has anyone investigated where there are magic ioctl's or libdevmapper APi's so we can get the RAID parameters automatically? If so, patches so that mke2fs can get the information automatically (as opposed to forcing the user to have to specify lots of annoying options) would be most welcome - 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
[GIT] Please pull ext4 bug fixes
Hi Linus, Please pull from the "for_linus" branch at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus It contains the following fixes, which (except for the superblock field reservations) have all been in the -mm tree for quite a while. Thanks, regards, - Ted fs/ext4/balloc.c|6 - fs/ext4/extents.c | 148 +++- fs/ext4/inode.c |4 - fs/ext4/namei.c |4 - fs/ext4/super.c |2 include/linux/ext4_fs.h | 33 +--- include/linux/ext4_fs_extents.h |5 - include/linux/ext4_fs_i.h |6 - 8 files changed, 134 insertions(+), 74 deletions(-) Alex Tomas (1): When ext4_ext_insert_extent() fails to insert new blocks Amit Arora (1): ext4: Extent overlap bugfix Dave Kleikamp (1): EXT4: Fix whitespace Mingming Cao (1): Remove unnecessary exported symbols. Theodore Ts'o (1): Define/reserve new ext4 superblock fields - 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
On Thu, 2007-05-31 at 12:16 -0400, Theodore Tso wrote: > On Thu, May 31, 2007 at 02:28:33AM +0530, Kalpak Shah wrote: > > > > So can I assume that the INCOMPAT_MMP flag and the s_mmp_interval and > > s_mmp_block superblock fields will be reserved regardless of whether the > > patches go into ext4? I had attached the patches in the last mail so you > > can share your views on them. > > Yes, i've reserved the code point and superblock fields. Thanks. > I'm not going to add INCOMPAT_MMP flag to the supported file until I get and > integrate the patch ext2fs_open() that actually tests for the flag, > though, since that would be a bit silly. > > I assume the patch will add a flag to ext2fs_open which skips the MMP > checking. Yes I have added a EXT2_FLAG_SKIP_MMP flag to ext2fs_open() to bypass MMP which will be set if tunefs is used with -f option. Also MMP check will not be run if the filesystem is being opened readonly. Thanks, Kalpak. > After all, tune2fs is allowed to make changes to the > superblock while the filesystem is mounted. So it needs to be able to > open the filesystem read/only even if it is mounted. > > Regards, > > - 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: [RFC] store RAID stride in superblock
On Thu, 2007-05-31 at 14:19 -0600, Andreas Dilger wrote: > On May 31, 2007 12:21 -0400, Theodore Tso wrote: > > On Thu, May 24, 2007 at 07:45:32PM +0530, Rupesh Thakare wrote: > > > I've added "s_raid_stripe_width" parameter in superblock. > > > I've also incorporated "s_raid_stride" and "s_raid_stripe_width" > > > parameters in tune2fs. > > > The new options can be specified using '-E options' in both mke2fs and > > > tune2fs. > > > Both the Man pages (mke2fs and tune2fs) are updated accordingly. > > > Patch is attached herewith. > > > > Thanks. I've used a different offset for the raid_stripe_width, to > > avoid conflicting with Kalpak's mmp patch. > > Ah, we've been doing it the other way around here. It makes sense to keep > the s_raid_stripe_width fields together. I think this code is preliminary > enough that nobody has actually started using it yet. Can you please post > what the end of ext2_super_block looks like (whether you decide to reorder > the fields or not). I can update the MMP patches when I actually send them for inclusion. So I think it makes sense to keep the s_raid_* fields together. Thanks, Kalpak. > > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. > > - > 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 - 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] store RAID stride in superblock
On May 31, 2007 12:21 -0400, Theodore Tso wrote: > On Thu, May 24, 2007 at 07:45:32PM +0530, Rupesh Thakare wrote: > > I've added "s_raid_stripe_width" parameter in superblock. > > I've also incorporated "s_raid_stride" and "s_raid_stripe_width" > > parameters in tune2fs. > > The new options can be specified using '-E options' in both mke2fs and > > tune2fs. > > Both the Man pages (mke2fs and tune2fs) are updated accordingly. > > Patch is attached herewith. > > Thanks. I've used a different offset for the raid_stripe_width, to > avoid conflicting with Kalpak's mmp patch. Ah, we've been doing it the other way around here. It makes sense to keep the s_raid_stripe_width fields together. I think this code is preliminary enough that nobody has actually started using it yet. Can you please post what the end of ext2_super_block looks like (whether you decide to reorder the fields or not). Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - 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 0/2] i_version update
On Thu, 2007-05-31 at 10:33 +1000, David Chinner wrote: > On Wed, May 30, 2007 at 04:32:57PM -0700, Mingming Cao wrote: > > On Wed, 2007-05-30 at 10:21 +1000, David Chinner wrote: > > > On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote: > > > > Hi, > > > > > > > > This is an update of the i_version patch. > > > > The i_version field is a 64bit counter that is set on every inode > > > > creation and that is incremented every time the inode data is modified > > > > (similarly to the "ctime" time-stamp). > > > > > > My understanding (please correct me if I'm wrong) is that the > > > requirements are much more rigourous than simply incrementing an in > > > memory counter on every change. i.e. the this counter has to > > > survive server crashes intact so clients never see the counter go > > > backwards. That means version number changes need to be journalled > > > along with the operation that caused the change of the version > > > number. > > > > > Yeah, the i_version is the in memeory counter. From the patch it looks > > like the counter is being updated inside ext4_mark_iloc_dirty(), so it > > is being journalled and being flush to on-disk ext4 inode structure > > immediately (On-disk ext4 inode structure is being modified/expanded to > > store the counter in the first patch). > > Ok, that catches most things (I missed that), but the version number still > needs to change on file data changes, right? So if we are overwriting the > file, we're calling __mark_inode_dirty(I_DIRTY_PAGES) which means you don't > get the callout and so the version number doesn't change or get logged. In > that case, the version number is not doing what it needs to do, right? > Hmm, maybe I missed something... but looking at the code again, in the case of overwrite (file date updated),it seems the ctime/mtime is being updated and the inode is being dirtied, so the version number is being updated. vfs_write()->.. ->__generic_file_aio_write_nolock() ->file_update_time() ->mark_inode_dirty_sync() ->__mark_inode_dirty(I_DIRTY_SYNC) ->ext4_dirty_inode() ->ext4_mark_inode_dirty() Regards, Mingming - 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] store RAID stride in superblock
On Thu, May 24, 2007 at 07:45:32PM +0530, Rupesh Thakare wrote: > Hello, > I've added "s_raid_stripe_width" parameter in superblock. > I've also incorporated "s_raid_stride" and "s_raid_stripe_width" > parameters in tune2fs. > The new options can be specified using '-E options' in both mke2fs and > tune2fs. > Both the Man pages (mke2fs and tune2fs) are updated accordingly. > Patch is attached herewith. Thanks. I've used a different offset for the raid_stripe_width, to avoid conflicting with Kalpak's mmp patch. Could you send me a signed-off-by for your patch? Thanks, - 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: [RFC][PATCH] Multiple mount protection
On Thu, May 31, 2007 at 02:28:33AM +0530, Kalpak Shah wrote: > > So can I assume that the INCOMPAT_MMP flag and the s_mmp_interval and > s_mmp_block superblock fields will be reserved regardless of whether the > patches go into ext4? I had attached the patches in the last mail so you > can share your views on them. Yes, i've reserved the code point and superblock fields. I'm not going to add INCOMPAT_MMP flag to the supported file until I get and integrate the patch ext2fs_open() that actually tests for the flag, though, since that would be a bit silly. I assume the patch will add a flag to ext2fs_open which skips the MMP checking. After all, tune2fs is allowed to make changes to the superblock while the filesystem is mounted. So it needs to be able to open the filesystem read/only even if it is mounted. Regards, - 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: [RESEND e2progs] get_backup_sb: Consider block size when searching for backups
On Tue, May 29, 2007 at 10:26:44PM +0100, Daniel Drake wrote: > I sent this in a few weeks ago, and it hasn't been applied to the hg tree. > Any comments? Thanks. Thanks, applied. Sorry for the delay. - 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: e2fsprogs coverity patch
On Tue, May 29, 2007 at 05:10:25PM -0600, Andreas Dilger wrote: > I also have another outstanding patch: > > === > Coverity ID: 6: Forward Null > > At the second conditional iter->file could still be NULL. We need to > check for it again. Also applied. - 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: Oops on disk write (kernel 2.6.16.y)
[linux-ext4 added to CC] Holger Eitzenberger napisał(a): > Hi, > > I am currently experiencing the same Kernel crash on several machines and > Kernel version 2.6.16.43. Attached are some dumps of one particular > machine which crashed several times because of this. Up until now I was > unable to reproduce this behaviour in the testlab, also putting some I/O > on the box helped not. > > All of them happened on UP kernels, but this may be just a coincidence. >>From the logs I see that at least in one case the machine didn't stop > immediately but worked for few our from that point on until it hit the > wall. > > Looking at the traces I can say that all of them follow a codepath from > the block I/O layer downward to ext3, e.g. here in page writeback path, > see: > > kernel: Unable to handle kernel NULL pointer dereference at virtual address > 0004 > kernel: printing eip: > kernel: c018e36a > kernel: *pde = > kernel: Oops: [#1] > kernel: Modules linked in: nfnetlink_queue ip_nat_ftp ip_conntrack_ftp > edd sg sd_mod sr_mod scsi_mod ide_cd cdrom ipt_MASQUERADE ipt_hashlimit > xt_condition ipt_REDIRECT xt_limit xt_conntrack ipt_esp xt_tcpudp > ipt_psd ipt_addrtype ip_nat_mms ip_nat_pptp ip_nat_irc iptable_nat > ebtable_nat ebtables iptable_ips ip_conntrack_mms ip_conntrack_pptp > ip_conntrack_irc ppp_deflate zlib_deflate bsd_comp sha1 > arc4 ppp_mppe ppp_async crc_ccitt ppp_generic slhc crypto_null blowfish > cast5 serpent twofish ipsec af_packet ipt_logmark ipt_confirmed > ipt_owner ipt_REJECT ipt_CONFIRMED evdev ehci_hcd uhci_hcd ohci_hcd > parport_pc ppdev parport xt_state xt_NOTRACK iptable_raw iptable_filter > ip_conntrack_netlink ip_nat ipt_LOG ip_conntrack ip_tables x_tables > nfnetlink_log nfnetlink eepro100 mii e100 capability commoncap loop > kernel: CPU:0 > kernel: EIP:0060:[]Not tainted VLI > kernel: EFLAGS: 00010286 (2.6.16.43-46-default #1) > kernel: EIP is at walk_page_buffers+0x1a/0x70 > kernel: eax: ebx: ecx: edx: > kernel: esi: edi: d5f3cb74 ebp: esp: c34a5d6c > kernel: ds: 007b es: 007b ss: 0068 > kernel: Process pdflush (pid: 22753, threadinfo=c34a4000 task=cd7cb070) > kernel: Stack: <0>d573c574 dbb7c720 dbb7c720 c1114540 dbb7c720 > d5f3cb74 dbb7c720 > kernel: c01919c3 1000 c018e3c0 cb6e1710 0246 c1114540 > 000a > kernel: c01918c0 c34a5f48 c0176979 c1114540 c34a5f48 c34a5e28 > 000e > kernel: Call Trace: > kernel: [] ext3_ordered_writepage+0x103/0x1f0 > kernel: [] bget_one+0x0/0x10 > kernel: [] ext3_ordered_writepage+0x0/0x1f0 > kernel: [] mpage_writepages+0x1c9/0x3e0 > kernel: [] ext3_ordered_writepage+0x0/0x1f0 > kernel: [] do_writepages+0x49/0x50 > kernel: [] __writeback_single_inode+0x8c/0x3c0 > kernel: [] schedule_timeout+0x4c/0xc0 > kernel: [] sync_sb_inodes+0x178/0x230 > kernel: [] writeback_inodes+0x6f/0x89 > kernel: [] wb_kupdate+0xf9/0x170 > kernel: [] pdflush+0x8e/0x180 > ... > > The disassembly of write_page_buffers() is at [1]. At least some of the > other crashes happen in the sys_write() path, I have attached some of > them ([2], [3] and [4]). > > Looking at the LKML archive I can say that > > http://lkml.org/lkml/2007/3/4/11 > > looks similar. > > Any help appreciated. > > Thanks. > > /holger > > > [1] > http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/walk_page_buffers.s > [2] > http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/kernel-2007-05-03.log.gz > [3] > http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/kernel-2007-05-10.log.gz > [4] > http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/kernel-2007-05-15.log.gz - 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: e2fsprogs coverity patch
On Tue, May 29, 2007 at 02:51:41PM -0600, Andreas Dilger wrote: > > Did cid-34.diff get lost? > > I still have it in my "apply atop 1.39-WIP" series, so it appears not > to have made it into Ted's repo. I'm including the patch again for > posterity. Fix applied. - 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 0/2] i_version update
On Thu, 2007-05-31 at 10:01 +1000, Neil Brown wrote: > This will provide a change number that normally changes only when the > file changes and doesn't require any extra storage on disk. > The change number will change inappropriately only when the inode has > fallen out of cache and is being reload, which is either after a crash > (hopefully rare) of when a file hasn't been used for a while, implying > that it is unlikely that any client has it in cache. It will also change inappropriately if the server is under heavy load and needs to reclaim memory by tossing out inodes that are cached and still in use by the clients. That change will trigger clients to invalidate their caches and to refetch the data from the server, further cranking up the load. Not an ideal solution... Trond - 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
