From kde Fri Apr 08 10:50:36 2011 From: gene heskett Date: Fri, 08 Apr 2011 10:50:36 +0000 To: kde Subject: [kde] Re: 4.6.2 early report Message-Id: <201104080650.36202.gheskett () wdtv ! com> X-MARC-Message: https://marc.info/?l=kde&m=130226010930257 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: 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 () 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) 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.