On Thu, Oct 21, 2010 at 10:29:02AM +0100, Gordan Bobic wrote:
> Herbert Poetzl wrote:
> >On Wed, Oct 20, 2010 at 03:02:25PM +0100, Gordan Bobic wrote:
> >>I have just tested this with a new kernel. And the issue doesn't arise
> >>with 188.8.131.52-vs184.108.40.206.33! So it is definitely a kernel bug, most
> >>likely in ext4.
> >>This really needs to be documented and stressed on the pages with
> >>download links. Hashify feature causes total data corruption with
> >>220.127.116.11-vs18.104.22.168.14-pre8 when used on ext4 without a journal.
> >well, thanks for investigating this, but you are
> >aware that _nobody_ is supposed to use that kernel
> >or patch anymore, as it was highly experimental
> >(see the pre) and superceeded by a working version
> That'd be fine if there was a non-pre patch available for that kernel
> - but there isn't. And due to other patch requirements that may not
> have been ported forward to new kernels, it is plausible that that
> somebody might be stuck with it. I wasn't using such an old kernel out
> of choice.
> If the patch shouldn't be used, it arguably shouldn't be linked on the
> download page.
the table is auto generated from the experimental download
area, but I took care of those patches and moved them
to the OBSOLETE folder so that they do not show up on
the experimental patch matrix anymore (at least after
the next automatic update)
> >in general, I'd stay away from kernels 2.6.25-2.6.31
> >especially with 'sensitive' filesystems like ext4,
> >reiserfs and btrfs ...
> Agreed, but as I said, sometimes you don't have a choice.
there is absolutely no reason to use that kernel or patch.
> >>I haven't tried other cases (ext4 with a journal or other file systems)
> >>so I cannot speak for those, but in the mentioned use cases it is
> >>completely repeatable.
> >if the issue persists in the recent kernel branches,
> >i.e. in 22.214.171.124 or even 2.6.33.x/2.6.35.x then
> >we need to investigate, otherwise I consider this
> >closed ...
> As I said, 126.96.36.199 works fine. I'm not suggesting this should be
> patched/fixed in vservers (I'm suspecting the bug is actually in ext4),
> but I do think it should be documented. We are talking about the latest
> available 2.5.30 kernel here (188.8.131.52), which isn't that far off from
> 184.108.40.206. Putting a note next to the link that says "there are known
> issues with this kernel that can lead to file system corruption" would
> go a long way toward saving people's data from stealthy corruption.
> Having a warning where it's due on the download page is vastly
> preferable to people writing on blogs things like "vservers sucks, it
> corrupted my data".
it is gone now, and I do not consider documenting every
potential mainline bug on Linux-VServer, specifically not
when the kernel is long outdated and the patch was just
a test release to see _if_ there are any issues with the
(back then) 'new' kernel ....
Received on Thu Oct 21 10:38:13 2010