2.4.15aa1

2.4.15aa1

[Andrea Arcangeli]

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

Re: 2.4.15aa1

[Paulo J. Matos aka PDestroy]

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 <andrea@suse.de> 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 majordomo@vger.kernel.org
> 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!

Re: 2.4.15aa1

[Andrea Arcangeli]

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

Re: 2.4.15aa1

[Phil Sorber]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.15aa1

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.4.15aa1

[Andrea Arcangeli]

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

Re: 2.4.15aa1

[bill davidsen]

In article <1006629351.1470.8.camel@praetorian> aafes@psu.edu 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 <davidsen@tmr.com>
  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.