[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde
Subject:    [kde] Re: 4.6.2 early report
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2011-04-08 8:57:41
Message-ID: pan.2011.04.08.08.57.40 () cox ! net
[Download RAW message or body]

gene heskett posted on Fri, 08 Apr 2011 02:33:30 -0400 as excerpted:

> On Friday, April 08, 2011 02:08:02 AM Duncan did opine:
> 
>> gene heskett posted on Thu, 07 Apr 2011 10:09:52 -0400 as excerpted:

>> > Wandering around in ~/.kde4, I found a bunch of what look like junk
>> > directories in .kde and .kde4 subdirs of .kde4 and nuked those, but
>> > what seems odd is that there are a lot of *rc files in .kde4/share
>> > that not even root can look at with less, no error when root tries,
>> > just no response.
>> 
>> That sounds VERY MUCH like filesystem damage, perhaps due to failing
>> storage hardware!  What filesystem are you using?
>> 
>> You mentioned amanda virtual tapes, so I assume you have good backups.
>> If not, be worried.
>> 
> I do.  I also have smartd watching things, but the only thing its
> consistently spamming the logs  with are tempurature changes. a degree
> up and back down, and those are arbitrary, usually in the 33C range.

Well, then, if it's hardware it's fooling smart too.  Which I've read 
about happening occasionally, but I'm already resting a bit better here, 
having read this and the rest of your post.

>>, If you're lucky and it's just the filesystem, not the hardware, a good
>> fsck should help.  Some of the data that /was/ in those files may end
>> up in lost&found, and the files will likely either be deleted or
>> truncated to zero size.
> 
> Does touching /.autofsck still work?

It's supposed to here on Gentoo.  Of course as I mentioned I run reiserfs, 
which is a bit of a special case in how it handles that.

>> Normally, *rc files shouldn't be in ~/.kde4/share/ itself.  Rather,
>> there's normally quite a few in share/config/, but none in share
>> itself.
> 
> share/config, yes, that is where they are, and perhaps I miss-typed.
> Ancient fingers don't always keep up with the thoughts driving them.

Good.  That's one less mystery to worry about!  At least we don't have 
files unpredictably wandering into different directories, now!

Given this and the above, it's likely an fsck will fix things.  Files that 
even root can't read does indeed remind me of filesystem damage and you 
still have those, but the files wandering into unexpected dirs appears to 
have been a false alarm so nothing to try to figure out there, and with 
backups and smart monitoring, I'm not as worried about hardware damage as 
I was initially.

> Using ext3/4, probably 4 on the /home partition.  We won't talk about
> our experience with reiserfs, it cost us about $1k

ext4 is good and of course ext3 is an old standby.  Yeah, a lot of people 
have had problems with reiserfs, but it has been good by me since the 
switch to data=ordered by default.  I was afraid you were going to say 
btrfs, the new and fancy filesystem, but they're still working on an fsck 
for it.

The one thing I'd still recommend you look into is again, data=ordered.  
AFAIK, ext4 defaults to the faster but less reliable data=writeback, which 
I blame for a good portion of the bad reputation reiserfs got, before it 
too introduced and began defaulting to data=ordered (as did ext3) some 
years ago.  Given the issues you mentioned with reiserfs and that I expect 
it was during the data=writeback years, you too should be rather 
interested in data=ordered over data=writeback.

The bit that gets me, however, is that for reasons that I never agreed 
with (the details involve a long story and quite some kernel politics so 
I'll leave it at that), for several kernel versions in the early 2.6.3x 
series, they changed the ext3 default to data=writeback as well.  For a 
stable filesystem in maintenance mode, even a lot of people who argue for 
data=writeback in general argued that was the wrong decision -- it should 
have stayed as it was, data=ordered by default.  It can even be argued 
that during that period, they made ext3 potentially less reliable than 
reiserfs by default, since notably, reiserfs still had the data=ordered 
default it has had since the feature was added to the official kernel, 
while ext3 was exposed to the perils of data=writeback during that period.

But whatever.  Except for people still running kernels between about 
2.6.31 and 2.6.36 inclusive, that's water under the bridge now, as the 
ext3 default was switched back to data=ordered.  I'm not positive about 
which version the default switched back, but believe 2.6.31 was the first 
one with the ext3 data=writeback default, and that they switched it back 
to data=ordered some time between 2.6.35 and 2.6.37.

Anyway, assuming those unreadable-by-root files are indeed filesystem 
damage as I expect, there's a fair chance it's due to data=writeback on 
that filesystem, be it ext3 or ext4.  For both of them, if it were my data 
on the filesystem and unless it was something I was comfortable sticking 
on a RAID-0 without redundancy or backup, I'd take tune2fs and ensure the 
filesystem was marked data=ordered in the filesystem itself,  
Additionally, make sure your mount options (or remount, for root) include 
the data=writeback option.

One other thing, tho I have less of an opinion on it as I simply don't 
have enough first-hand knowledge or experience to fairly get such an 
opinion, for ext4, you may want to evaluate whether the delayed allocation 
feature is worth it or not, for you.  Turning off delayed allocation WILL 
have a performance impact and will result in less optimal file layout 
since it can't wait until the last moment to reserve space, thus putting 
any additional info it got in the mean time into the mix as well, but it 
is arguably less risky, data-integrity-wise.

>> In addition to the disks I'd check your power supply.  Perhaps the
>> problem is that it doesn't have enough power for the disks, or perhaps
>> your incoming power simply isn't good.
> 
> gkrellm has been watching that, its holding well at plus 2% of nominal.
> And the ups, a 1500wa unit, handles the glitches in the power.

=:^)

>> > And my konsoles are AFU again, foreground & background colors are
>> > randomized but matched, so one can't see the output till he does a
>> > mouse drag over the output to highlight it.
>> > 
>> > mc seems to be slowly self destructing too.
>> > 
>> > I may yet have to re-install on a different drive. :-(
>> 
>> Given the indications, that may well be a good idea!

It definitely sounds like something went wrong with things somewhere.  I'd 
do that fsck, see if that cured the root-can't-read files, do a reinstall 
to hopefully get anything that might have been screwed up there straight, 
and then deal with the user stuff.  At this point, it sounds like the 
install and/or user config is quite screwed, but there's no sense trying 
to straighten it out until you get those root-can't-read files straight.  
Once that's straightened out, and the system level kde reinstalled, just 
to be sure, /then/ reevaluate where things are with the user stuff, and go 
from there.

>> Good luck!  It sounds like you might need a bit, right now!
> 
> Better health would be a plus right now.  Despite current on pneumonia
> shots, they are treating me as if I have it. 10 pills, $181 & change.
> And at my age, that can be a scary thought.

IIRC you said you're 76 in another post.  If so, you have me beat by three 
decades.  If I'm keeping up with computers as well as you seem to be by 
then, I'll consider myself lucky indeed.

> I may go get a fresh 64 bit
> pclos cd and put it on /dev/sdb tomorrow.  This is a 32 bit install, but
> I think 64 has pretty well caught up these days. I even hear flash can
> be had in 64 bit now.

I've been running 64-bit-only Gentoo (amd64 no-multilib, is what that 
profile's called here) for years.  But I won't have proprietaryware 
including flash on my system (neither could I, legally, since I can't 
agree to the EULA accept a liability waiver for black-box software I can't 
even inspect or have a friend I trust inspect, to see what I'm signing off 
on!), so once the open stuff was ported, I didn't have to worry about it 
like the folks still trying to jump thru the proprietary hoops do, and 
that make things far easier.

> I haven't run memtest86 recently either, and its possible I need to
> reseat the sticks, I have had to do that 2x before. A $300 Asus mobo has
> crappy memory sockets!

I've been very happy with my now nearing 8 years' old Tyan dual socket 
Opteron.  The CPUs are maxed at dual 290s (dual-core 2.8 GHz, so dual-dual-
core for four cores), registered DDR-1 memory, etc.  $400+ board, but it's 
looking like it might have a decade on it 'time I'm done.  I've had some 
problems with bad memory, but the sockets are fine.  I've been satisfied.

> Thanks & good night.

'bout that time for me, too.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
[prev in list] [next in list] [prev in thread] [next in thread]