Repeated Filesystem Corruption
in [UK Mac]
|
Prev: AIFF editor and creator for short tunes
Next: Full Moon
From: Ben Shimmin on 12 Jul 2010 16:04 R <me32(a)privacy.net>: [...] > drwxrwxrwx 2 root wheel 68 31 May 08:49 > /lost+found/1502381/D18476.lck [...] > The last four were modified on the 3rd, 4th, 5th and 6th of > July respectively. If I take a look at the fsck log I find these > entries for those days: > > /dev/rdisk0s2: fsck_hfs run at Sat Jul 3 12:50:26 2010 > /dev/rdisk0s2: ** /dev/rdisk0s2 (NO WRITE) > /dev/rdisk0s2: ** Root file system > /dev/rdisk0s2: Executing fsck_hfs (version diskdev_cmds-491.2~2). [...] > The modified times of the "lck" files seem to correspond to the > times when fsck was being run, more or less. Looking through > the kernel log, I can see that's just after booting. > > 3 of those ".lck" files have the same name: D51501.lck. I wonder > if that's significant. Hard to say without knowing what the files are. From fsck(8)'s manpage: Orphaned files and directories (allocated but unreferenced) are, with the operator's concurrence, reconnected by placing them in the lost+found directory. The name assigned is the inode number. b. -- <bas(a)bas.me.uk> <URL:http://bas.me.uk/> `Zombies are defined by behavior and can be "explained" by many handy shortcuts: the supernatural, radiation, a virus, space visitors, secret weapons, a Harvard education and so on.' -- Roger Ebert
From: Mark Bestley on 13 Jul 2010 10:31 R <me32(a)privacy.net> wrote: > p.s. I've just downloaded the fsck source code from apple. It's in this: > > http://www.opensource.apple.com/tarballs/diskdev_cmds/diskdev_cmds-491.2 > .tar.gz > > This finds nothing: > > find diskdev_cmds-491.2 -exec grep "lck" {} \; Dosn't lost+_found hold the root files that have been 'lost'. If the file is a directory then the files and subdirectoroies are linked to the lost directory and so just can be read by ls etc from the inode in lost_found. Thus in your case just the root directory os lost and the D*.lck are just what was in the directory. So they result from normal file use. -- Mark
From: Graham J on 13 Jul 2010 13:12 "R" <me32(a)privacy.net> wrote in message news:1jlipde.zw15df1chxtq8N%me32(a)privacy.net... > Andrew Hodgkinson <ahodgkin(a)rowing.org.uk> wrote: > >> Otherwise, I suggest you try a clean installation of OS X at your >> earliest convenience - you should not be seeing regular filesystem >> corruption. The only time I've ever needed to repair a disc on Tiger >> through to Snow Leopard is due to the machine being switched off without >> being shut down. Once you've got the clean installation, verify that >> corruption is no longer happening. After you reinstall your applications, >> if corruption reappears, then you know that some 3rd party software you >> just installed is to blame. > > That seems like sound advice. However, I don't really want to > go a month or two without 3rd party software, which is about how > long it would take to convince me the problem has probably gone. > > I'm wondering if more can be done in the way of direct diagnosis. > There are still those pesky files in lost+found. Perhaps there is a > pattern there to be discovered. I would like to know, too, what > exactly fsck (if that's what Disk Utility is using) has fixed. Build an exact duplicate of the system, install the same software on it, see if the same problems occur ... -- Graham J
From: Chris Ridd on 13 Jul 2010 13:13 On 2010-07-13 16:55:36 +0100, R said: > Mark Bestley <news{@bestley.co.uk> wrote: > >> Thus in your case just the root directory os lost and the D*.lck are >> just what was in the directory. So they result from normal file use. > > Are you suggesting that those D*.lck names might have > been actual filenames of lost files (as opposed to names > generated by fsck, say)? > > If that is the case, then it is interesting. Because you'd > expect random filesystem corruption to result in the loss > of random files, with all sorts of different names. > > The only files with D*.lck names I can find are currently > in lost+found. I searched with the following command: > > find / -name "D*.lck" > > However, I guess it's possible that files with such names > do appear elsewhere in the filesystem on occasion, but > don't happen to be there now. Are they directories, or filenames? If they're directories they shouldn't ever occur if journaling's enabled on the filesystem. -- Chris
From: Mark Bestley on 13 Jul 2010 14:14
R <me32(a)privacy.net> wrote: > Mark Bestley <news{@bestley.co.uk> wrote: > > > Thus in your case just the root directory os lost and the D*.lck are > > just what was in the directory. So they result from normal file use. > > Are you suggesting that those D*.lck names might have > been actual filenames of lost files (as opposed to names > generated by fsck, say)? > Yes > If that is the case, then it is interesting. Because you'd > expect random filesystem corruption to result in the loss > of random files, with all sorts of different names. > I would guess that one program is causing this then, > The only files with D*.lck names I can find are currently > in lost+found. I searched with the following command: > > find / -name "D*.lck" > Which user owns them - ie ls -l on them. > However, I guess it's possible that files with such names > do appear elsewhere in the filesystem on occasion, but > don't happen to be there now. Googling for .lck and OSX prompts the question do you use VMWare? -- Mark |