Just a small question, bertl:
Poeple that use vserver in production environment want a stable
environment. If you ever want linux-vserver to become something widely
used and accepted, there should be a stable patch, there should be
warnings if something is wrong and so on... You should inform people as
much as possible and cooperate with people doing packaging for
distributions. As i get it, you hate every distribution in the world and
don't want to have anything to do with their patches.
If you just say: that's a crappy kernel, just upgrade... it's fun when
you're playing around. not if you 've been doing tests etc for weeks
before putting stuff in production.
Right now, what we have is a very clear dev version of util-vserver, a 2.3
patch series that's relatively stable and testing version of the utilities
All the rest is is very old (kernel 2.6.22 and 0.30.215 of util-vserver).
Whenever someone asks a question about a kernel that old or version of
util-vserver that's that old, you just say: upgrade to the latest. so
essentially, you're saying "put the latest unstable/testing kernel in
production, but don't complain if it dies, because i call it dev, so
you're on your own."
All that i do for the grsecurity/linux-vserver patch, i just do because
people want it. There are many people that really use it and find it
so here's the question: What is your view on this project? do you really
hate all the users that want this to be production-ready? do you really
hate the grsec/vserver patch? if so, just say so, and i will stop doing
anything all together.
If you keep saying: you're using a distro kernel, so screw you!, i don't
want to be involved. It's normal that people want something that WORKS. If
you say: the only thing worth running now is 2.3 with the latest
util-vserver, then make it stable/support it/whatever! but don't tell
people "there is no reason not to upgrade to the latest version of
everything", when that version is unstable and not working properly
Sorry for my rant, but some people here (including me) would like
something stable that's not almost 3 years old. If not, this project can
be considered dead and people will abandon this project.
so for me it's time to choose: or, you start making it work and start
or, this project will die because of frustration of all the users that
just get a : you don't have the latest utils that just got out yesterday
and you don't use the patch i uploaded 2 days ago.
just my 2 cents,
> 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 220.127.116.11-vs18.104.22.168.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
>> >>22.214.171.124-vs126.96.36.199.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
>> >>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 188.8.131.52 or even 2.6.33.x/2.6.35.x then
>> >we need to investigate, otherwise I consider this
>> >closed ...
>> As I said, 184.108.40.206 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 (220.127.116.11), which isn't that far off from
>> 18.104.22.168. 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 13:27:27 2010