Note: the "00_read_super-stale-inode-1" fix is under discussion with Al,
but overall it should be just ok for public consumation (even if that
are may change if we find any better alternative, at the moment I think
it is better (cleaner, simpler and faster) alternative than the iput
changes in function of the MS_ACTIVE info).
URL:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.15aa1.bz2
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.15aa1/
Only in 2.4.15aa1: 00_iput-unmount-corruption-fix-1
Fix iput umount corruption.
Only in 2.4.15aa1: 00_read_super-stale-inode-1
If read_super fails avoid lefting stale inodes queued into
the superblock.
Only in 2.4.15pre9aa1: 10_vm-16
Only in 2.4.15aa1: 10_vm-17
Dropped a leftover touch_buffer in bread (there's just one in getblk in
-aa, and we need it in getblk [not only for reiserfs]).
Andrea
Will this fix the potential possibility of 2.4.15 screwing my
system? (inode problem as people have been mentioning it, etc?)
Best regards,
Paulo
Andrea Arcangeli <[email protected]> writes:
> Note: the "00_read_super-stale-inode-1" fix is under discussion with Al,
> but overall it should be just ok for public consumation (even if that
> are may change if we find any better alternative, at the moment I think
> it is better (cleaner, simpler and faster) alternative than the iput
> changes in function of the MS_ACTIVE info).
>
> URL:
>
> ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.15aa1.bz2
> ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.15aa1/
>
> Only in 2.4.15aa1: 00_iput-unmount-corruption-fix-1
>
> Fix iput umount corruption.
>
> Only in 2.4.15aa1: 00_read_super-stale-inode-1
>
> If read_super fails avoid lefting stale inodes queued into
> the superblock.
>
> Only in 2.4.15pre9aa1: 10_vm-16
> Only in 2.4.15aa1: 10_vm-17
>
> Dropped a leftover touch_buffer in bread (there's just one in getblk in
> -aa, and we need it in getblk [not only for reiserfs]).
>
> Andrea
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Paulo J. Matos aka PDestroy : pocm(_at_)rnl.ist.utl.pt
Instituto Superior Tecnico - Lisbon
Software & Computer Engineering - A.I.
- > http://www.rnl.ist.utl.pt/~pocm
---
Yes, God had a deadline...
So, He wrote it all in Lisp!
On Sat, Nov 24, 2001 at 09:45:39AM +0000, Paulo J. Matos aka PDestroy wrote:
>
> Will this fix the potential possibility of 2.4.15 screwing my
> system? (inode problem as people have been mentioning it, etc?)
yes.
Andrea
On Sat, 2001-11-24 at 02:50, Andrea Arcangeli wrote:
> Only in 2.4.15aa1: 00_iput-unmount-corruption-fix-1
>
> Fix iput umount corruption.
Is this the problem that Al put out a patch for yesterday? And is his
patch been tested and working?
> Only in 2.4.15aa1: 00_read_super-stale-inode-1
>
> If read_super fails avoid lefting stale inodes queued into
> the superblock.
What is this? How dangerous is it?
--
Phil Sorber
AIM: PSUdaemon
IRC: irc.openprojects.net #psulug PSUdaemon
GnuPG: keyserver - pgp.mit.edu
On Sat, Nov 24, 2001 at 02:15:50PM -0500, Phil Sorber wrote:
> Is this the problem that Al put out a patch for yesterday? And is his
> patch been tested and working?
I'm running it 2.4.15-viro three systems here with no detectable problems.
One has been building lots of kernels, the other has been sitting rather
idle, except for the occasional redhat package build, and has been rebooted
a few times. These are using a mixture of ext2 and NFS.
The last system is my firewall, which I don't expect to show any problems
with or without Al's fix, since it's running completely diskless (ie, NFS).
Naturally, they're all ARM boxen.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, Nov 24, 2001 at 02:15:50PM -0500, Phil Sorber wrote:
> On Sat, 2001-11-24 at 02:50, Andrea Arcangeli wrote:
> > Only in 2.4.15aa1: 00_iput-unmount-corruption-fix-1
> >
> > Fix iput umount corruption.
>
> Is this the problem that Al put out a patch for yesterday? And is his
> patch been tested and working?
it's an alternate fix (goes back to the pre8 way).
>
> > Only in 2.4.15aa1: 00_read_super-stale-inode-1
> >
> > If read_super fails avoid lefting stale inodes queued into
> > the superblock.
>
> What is this? How dangerous is it?
pre8 and all previous kernels could left a stale inode if read_super
failed after an iget [see the discussion with Al on l-k]. this patch
should fix it in practice for all fs in the kernel.
Andrea
In article <1006629351.1470.8.camel@praetorian> [email protected] asked:
| -=-=-=-=-=-
|
| On Sat, 2001-11-24 at 02:50, Andrea Arcangeli wrote:
| > Only in 2.4.15aa1: 00_iput-unmount-corruption-fix-1
| >
| > Fix iput umount corruption.
|
| Is this the problem that Al put out a patch for yesterday? And is his
| patch been tested and working?
|
| > Only in 2.4.15aa1: 00_read_super-stale-inode-1
| >
| > If read_super fails avoid lefting stale inodes queued into
| > the superblock.
|
| What is this? How dangerous is it?
Good question. As I read the patch, the problem occurs during umount,
when dirty inodes are not (properly) written to the disk. Would a sync()
help or eliminate this problem, assuming that all files were closed?
Hopefully someone knows, I don't want to tell you it only happens at
umount, but that's my impression.
In any case, since 2.4.16 is out (so much for "2.4.15 released without
embarrassment") to fix the problem, I would go with that unless you have
a reason to use whichever patch pleases you.
--
bill davidsen <[email protected]>
His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.