Hi,
On Wed, Jun 12, 2002 at 12:12:30PM +0100, Nigel Metheringham wrote:
> On Tue, 2002-06-04 at 00:06, Andrew Morton wrote:
> > Memory fails me... But no, we shouldn't be treating ENOSPC in that
> > manner. How about this?
>
> I'm getting some similar interesting errors to this - unfortunately I
> don't now have the Oops listing (too many things died on the box).
>
> This is on a 2.4.19-pre3 box - too early to have Stephen's last batch of
> updates applied, so I am building that now.
>
> However there are some:-
> kernel: EXT3-fs error (device ida0(72,8)) in ext3_new_inode: error 28
>
> [device is a compaq RAID controller], error 28 is ENOSPC.
>
> I see in ialloc.c that there is already some special treatment for
> ENOSPC that would skip around the ext3_std_error call, but then ENOSPC
> is also used for other purposes ("Free inodes count corrupted in group
> %d")....
>
> In my case I think I probably am hitting the limit of inodes on the
> system - after getting the box back into action it was 80% inodes used
> all in one directory and the app may well have chewed some more.
>
> Is conditionalising the ext3_std_error call like in Andrew's patch a
> sensible thing to do in this case? I've attached the equivalent patch
> (against 2.4.19-pre10-ac2).
It's already in the ext3 CVS and in current -ac (not quite Andrew's
patch, but something equivalent.)
--Stephen
