4.6.2 early report
Duncan
1i5t5.duncan at cox.net
Fri Apr 8 09:57:41 BST 2011
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.
More information about the kde
mailing list