4.6.2 early report

gene heskett gheskett at wdtv.com
Fri Apr 8 11:50:36 BST 2011

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
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 

> > 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
> 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 at 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)
<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.

More information about the kde mailing list