On Friday, April 08, 2011 06:23:40 AM Duncan did opine:
[...]
> > 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.
>
I will do that, and reboot in a few minutes. Because I have /var on its
own partition, this always involves a tap of the reset button as the
shutdown gets to:
turning off swaps
-f
and hangs due to /var already having been unmounted & it can't get a
lockfile opened.
I know, that is not preferred, but having had a couple of instances where
an error made / into read-only, that prevented the logs from recording any
trace of the error, and was pure hell to troubleshoot, the first time I
just re-installed. So I am adament about /var being on its own partition
just to prevent the loss of logging when the main / goes tits up. IMO, the
shutdown scripts that cannot work under those conditions are hopelessly
broken.
> > 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.
>
mount says everything is ext3, defaults
> 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.
Yes, I read through all that, be on lkml for about a decade. :)
> 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.
Currently at 2.6.38.2
> 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.
What is the syntax to extract that info?, the -l output as shown below
doesn't say.
> 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.
Thank you. I might add that my formal education stops at the 8th grade,
but I've been roping electrons for a living since school gave up on me in
'49. They taught me how to read, and that reading was fun, which is all
they needed to do for me. But I am also suffering from the old fart malady
about short term memory enough that it bothers the hell out of me.
'bout 6:30am, the cough is worse. But I can't seem to get tune2fs to spit
out the journal mode with a -l. The output for / is:
[root@coyote gene]# tune2fs -l /dev/sda3
tune2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: sea-slash
Last mounted on: <not available>
Filesystem UUID: 3d923d41-fe1d-49b2-9618-c03005888c41
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6406144
Block count: 25599577
Reserved block count: 1279978
Free blocks: 22163974
Free inodes: 6321616
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1017
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Wed Jul 14 00:23:04 2010
Last mount time: Thu Apr 7 08:41:28 2011
Last write time: Thu Apr 7 08:41:28 2011
Mount count: 179
Maximum mount count: -1
Last checked: Wed Jul 14 00:23:04 2010
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 6acfae34-c869-4806-9db8-8795ddf6f57a
Journal backup: inode blocks
I'm off to do a full powerdown reboot, and at least 1 full cycle of
memtest86. /.autofsck touched. With 4Tb of fscking to do, I won't say
brb. :-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
<Omnic> another .sig addition
___________________________________________________
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.
