Was hoping 2.6.17 would be out within one week, doesn't look like it
is going to happen.
My thesis defense is coming up, need to merge my patches against some kernel
(requiring 2.6.16.1 looks weird).
On a machine that 2.6.16.1 runs bug-free, is it sane to assume
2.6.17-rc3 will as well?
If it fails outright, I can revert, but if it is unstable I'm going to
have some problems.
(You would be surprised how long it took me to discover a mistake that
sys_rename(on any filesystem) -> deadlock with my custom patch).
On 5/9/06, Joshua Hudson <[email protected]> wrote:
> Was hoping 2.6.17 would be out within one week, doesn't look like it
> is going to happen.
It'll be released when it is ready, not according to a fixed
schedule... and yes, within one week looks unlikely.
> My thesis defense is coming up, need to merge my patches against some kernel
> (requiring 2.6.16.1 looks weird).
>
> On a machine that 2.6.16.1 runs bug-free, is it sane to assume
> 2.6.17-rc3 will as well?
I'd say no.
2.6.17-rc3 is a development kernel, no guarantees about anything really.
If you want a newer kernel stable kernel, then your safest bet would
be the latest -stable one, currently that would be 2.6.16.15
> If it fails outright, I can revert, but if it is unstable I'm going to
> have some problems.
Development kernels are run completely at your own risk. It may run
fine, it may explode at boot, it may cause slow silent corruption, it
may eat your lunch, it may cause an alien invasion - all bets are
off... (although it actually seems to be getting pretty good, I've
been running 2.6.17-rc3-git12 without problems for a while).
> (You would be surprised how long it took me to discover a mistake that
> sys_rename(on any filesystem) -> deadlock with my custom patch).
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
> Was hoping 2.6.17 would be out within one week, doesn't look like it
> is going to happen.
> My thesis defense is coming up, need to merge my patches against some kernel
> (requiring 2.6.16.1 looks weird).
>
Surprisingly I'm in the same position ^_^ Basing my patches on 2.6.16 makes
a lot of changes produce compiler warnings again (e.g. due to changed
prototypes in ipt_* matches and targets).
> On a machine that 2.6.16.1 runs bug-free, is it sane to assume
> 2.6.17-rc3 will as well?
> If it fails outright, I can revert, but if it is unstable I'm going to
> have some problems.
> (You would be surprised how long it took me to discover a mistake that
> sys_rename(on any filesystem) -> deadlock with my custom patch).
If it is a kernel problem, report it. If it is a problem of your patch,
well, I suppose you need to fix it then. :/
Jan Engelhardt
--
>
> 2.6.17-rc3 is a development kernel, no guarantees about anything really.
> Development kernels are run completely at your own risk. It may run
> fine, it may explode at boot, [...], it may eat your lunch, it may cause
> an alien invasion -[...]
Quite a list. So what can -mm kernels make go wrong more? :-]
Jan Engelhardt
--
On Wednesday 10 May 2006 08:34, Jan Engelhardt wrote:
> > 2.6.17-rc3 is a development kernel, no guarantees about anything really.
> > Development kernels are run completely at your own risk. It may run
> > fine, it may explode at boot, [...], it may eat your lunch, it may cause
> > an alien invasion -[...]
>
> Quite a list. So what can -mm kernels make go wrong more? :-]
Well, back in the 2.5 days, JFS/-mm ate my filesystem, which is possibly worse
than it eating my lunch, and more relevant to me than an alien invasion...
Though, Joshua, 2.6.17-rc3 seems to be a rock-solid release. It's safe enough
to diff against and boot, if that's what you want to do.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
>
>Though, Joshua, 2.6.17-rc3 seems to be a rock-solid release. It's safe enough
>to diff against and boot, if that's what you want to do.
>
It did not eat the virtual machine so its chances are good. However, I wait
for 2.6.17 because of the few XFS fixes gone in since then.
Jan Engelhardt
--
On Wednesday 10 May 2006 23:23, Jan Engelhardt wrote:
> >Though, Joshua, 2.6.17-rc3 seems to be a rock-solid release. It's safe
> > enough to diff against and boot, if that's what you want to do.
>
> It did not eat the virtual machine so its chances are good. However, I wait
> for 2.6.17 because of the few XFS fixes gone in since then.
I run a 1TB XFS filesystem on a RAID5 with no ill-effects. I've never
experienced data-loss in 2.6, mostly due to conservative options (no 4k
stacks, no regparm, XFS only).
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
>> >Though, Joshua, 2.6.17-rc3 seems to be a rock-solid release. It's safe
>> > enough to diff against and boot, if that's what you want to do.
>>
>> It did not eat the virtual machine so its chances are good. However, I wait
>> for 2.6.17 because of the few XFS fixes gone in since then.
>
>I run a 1TB XFS filesystem on a RAID5 with no ill-effects. I've never
>experienced data-loss in 2.6, mostly due to conservative options (no 4k
>stacks, no regparm, XFS only).
>
Oh I must have missed -rc2, in which
Nathan Scott:
[XFS] Fix superblock validation regression for the zero imaxpct case.
[XFS] Fix a writepage regression where we accidentally stopped
honouring
[XFS] Fix utime(2) in the case that no times parameter was passed in.
[XFS] Fix a problem in aligning inode allocations to stripe unit
got in.
Jan Engelhardt
--