Hi folks,
If I run "e2fsck /dev/sda5" I get the following error:
/dev/sda5 contains a filesystem with errors, check forced: Pass 1: Checking inodes, blocks and sizes Pass 2: Checking directory structure Missing '..' in directory inode 195 Fix <y>? yes Missing '..' in directory inode 196 Fix <y>? yes Pass 3: Checking directory connectivity Unmounted directory inode 195 (/???) Connect to /lost+found <y>? yes /lost+found not found. Create <y>? yes Error creating /lost+found directory (ext2fs_link): No free space in the directory
I am confused. If I mount /dev/sda5 on /mnt and have a look around it, it all looks ok and if I do a df it tells me there is still plenty of free space on the partition (as I expected): Filesystem: /dev/sda5 1k-blocks: 3958767 Used: 1653871 Available: 2100069 Use%: 44%
Anyone know how I can correct this "lost+found" error?
Ian.
on Fri, Nov 30, 2001 at 04:29:13PM -0000, Ian Douglas wrote:
Pass 3: Checking directory connectivity Unmounted directory inode 195 (/???) Connect to /lost+found <y>? yes /lost+found not found. Create <y>? yes Error creating /lost+found directory (ext2fs_link): No free spacein the directory
I am confused. If I mount /dev/sda5 on /mnt and have a look around it, it all looks ok and if I do a df it tells me there is still plenty of free space on the partition (as I expected): Filesystem: /dev/sda5 1k-blocks: 3958767 Used: 1653871 Available: 2100069 Use%: 44%
Anyone know how I can correct this "lost+found" error?
What does df -i /dev/sda5 say? it's possible it has run out of inodes if you have lots of small files.
on Fri, Nov 30, 2001 at 04:29:13PM -0000, Ian Douglas wrote:
Pass 3: Checking directory connectivity Unmounted directory inode 195 (/???) Connect to /lost+found <y>? yes /lost+found not found. Create <y>? yes Error creating /lost+found directory (ext2fs_link): No free
space
in the directory
I am confused. If I mount /dev/sda5 on /mnt and have a look around it,
it
all looks ok and if I do a df it tells me there is still plenty of free space on the partition (as I expected): Filesystem: /dev/sda5 1k-blocks: 3958767 Used: 1653871 Available: 2100069 Use%: 44%
Anyone know how I can correct this "lost+found" error?
What does df -i /dev/sda5 say? it's possible it has run out of inodes if
you
have lots of small files.
Hi Xsprite,
/dev/sda5 is indeed a data, rather than an operating system, partition so you are correct in thinking it does contain a lot of my own user files however "df -i /dev/sda5" says:
Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda5 1026048 9023 1017025 1% /mnt
Ian.
on Fri, Nov 30, 2001 at 07:48:47PM -0000, Ian Douglas wrote:
/dev/sda5 is indeed a data, rather than an operating system, partition so you are correct in thinking it does contain a lot of my own user files however "df -i /dev/sda5" says:
Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda5 1026048 9023 1017025 1% /mnt
ok, i just had a look through the fsck source code. libext2fs is generating the error in link.c, function link_proc.
fsck appears to be unable to allocate space for the actual name of the directory ("lost+found") in its parents directory ("/mnt"). It has managed to allocate an inode for the directory.
I'm not entirely sure, but fsck doesn't appear to be able to grow the size of a directory. So if you've filled the directory up to just below it's current "size" (say, 4090), but the kernel hasn't expanded it yet, then from my reading of the fsck source code, fsck isn't able to increase the "size" of that directory, so it fails.
fsck does appear to have the ability to expand the size of the lost+found directory, but only that directory. This seems odd, because libext2fs does have the functions to do this for any directory.
(silly question) Have you tried mkdir /mnt/lost+found? I don't know the effect of doing this, it could cause your computer to spontaneously combust, back up your data first, etc, etc.
If that fails, it might be a case of rolling up sleaves and having a go with debugfs.
on Fri, Nov 30, 2001 at 11:32PM, xprite@bigfoot.com wrote:
(silly question) Have you tried mkdir /mnt/lost+found? I don't know the effect of doing this, it could cause your computer to spontaneously combust, back up your data first, etc, etc.
If that fails, it might be a case of rolling up sleaves and having a go
with
debugfs.
Hi Xsprite,
First of all a public "Thank You" for your prompt help and advice regarding my query. It can be very unnerving to a newbie to encounter a serious/fatal sounding filesystem problem he doesn't understand. There is a great temptation to simply curse, reformat the hard disk, and reinstall things from the CD/backups but I didn't want to do that as it would mean I missed out on an opportunity to experiment and learn from what has happened. There is no doubt I could have quickly reinstalled my system and promised faithfully to myself to read up about it later (which I probably would never have got round to), however I understand things better by "getting my hands dirty" and experimenting (I guess this is what is attracting me to Linux) so with trembling fingers I did indeed try simply typing "mkdir /mnt/lost+found" as you suggested and have sent you (off-list as it is quite long) the output I subsequently got from e2fsck after unmounting /dev/sda5. I am very much a Linux newbie and probably wont understand what you say but is there any chance of explaining the problems e2fsck found with my filesystem, and what it did to correct them, so I (and perhaps other list subscribers) can learn a little more about the Linux filesystem from this problem? Alternatively, is there a good book/help file/web page somewhere which you could recommend to anyone who wants to learn a little more about Linux filesystems (and perhaps more about the debugfs program you mentioned) to use as a reference for future filesystem crashes?
Ian.
on Sat, Dec 01, 2001 at 12:10:01PM -0000, Ian Douglas wrote:
I am very much a Linux newbie and probably wont understand what you say but is there any chance of explaining the problems e2fsck found with my filesystem, and what it did to correct them, so I (and perhaps other list subscribers) can learn a little more about the Linux filesystem from this problem?
In summary (feel free to post any of my reply to you): By mkdir'ing lost+found, it will have either (or both):
1. Increased the size of the root directory of /dev/sda5 2. Attached or forced the recreation of the lost+found directory.
There were several inconsistancies on the filesystem, including duplicate usage of blocks where two inodes (essentially files) were claiming the to use the same blocks as each other. (explaination of inodes on foldoc.org) '.' and '..' entries were missing from lost+found directory or misplaced, for some reason. fsck added them in the correct place.
4 directories were unconnected from the filesystem. They existed but weren't refered to by anything directly. These 4 directories also had incorrect reference counts. Each time an inode is refered to, it's reference count is increased. When this reference count reaches 0, it is deleted. fsck attached these directories to the filesystem in /lost+found (relative to /dev/sda5), and updated the reference counts.
Various accounting information (block usage, block bitmaps, inode and directory counts) was incorrect, because of corrections above, and an inconsistent state. fsck corrected this by calculating the information from other sources.
Alternatively, is there a good book/help file/web page somewhere which you could recommend to anyone who wants to learn a little more about Linux filesystems (and perhaps more about the debugfs program you mentioned) to use as a reference for future filesystem crashes?
http://www.linuxdoc.org/LDP/LG/issue21/ext2.html is extremely good. There also is the Linux 2.4 kernel internals book, but this isn't for the faint hearted. http://www.linuxdoc.org/LDP/lki/index.html
There is also a book (that I am yet to get my hands on..) which is very good, although not linux specific (more solaris/sunos specific), it gives a good overview and explaination of techniques. It is aptly called "PANIC! UNIX System crash dump analysis handbook".
Another book covers this and filesystem handling itself, although again for a different operating system; "Design and Implmentation of 4.4BSD". (ext2 is based loosely on the BSD Fast filesystem)
debugfs can be used to manipulate the filesystem at a very low level. It is possible to put a filesystem in the state yours was in as well as attempt to recover it. To use it, though, it is really a good idea to have a good understanding of the underlying filesystem. The man page documents all the fun things you can do with it. I suspect the expand_dir and ln commands (from within debugfs) might have helped in this instance.
If you wish to play with debugfs without messing up a real partition, then you can create a loopback filesystem. This is done as follows:
~/tmp > dd if=/dev/zero of=testfs bs=400k count=1 1+0 records in 1+0 records out ~/tmp > mkfs.ext2 testfs mke2fs 1.15, 18-Jul-1999 for EXT2 FS 0.5b, 95/08/09 testfs is not a block special device. Proceed anyway? (y,n) y ... Writing inode tables: done Writing superblocks and filesystem accounting information: done ~/tmp > debugfs -w testfs debugfs 1.15, 18-Jul-1999 for EXT2 FS 0.5b, 95/08/09 debugfs: ls 2 (12) . 2 (12) .. 11 (1000) lost+found debugfs:
"?" will show available commands. "q" quits. The -w option to debugfs enables writing back to the filesystem (it will only let you do serious damage with -w)
on Sat, Dec 01, 2001 at 1:00PM xsprite@bigfoot.com wrote:
..... The man page documents all the fun things you can do with it. I suspect the expand_dir and ln
commands
(from within debugfs) might have helped in this instance.
If you wish to play with debugfs without messing up a real partition, then you can create a loopback filesystem. This is done as follows.........
I like the way you said "fun". I think that is really the key to enjoying and learning about Linux, especially for a newbie like myself. Not having the worries of using Linux for a living means I can sit back, relax, and enjoy experimenting with it without ever having to worry about department heads/boss/users breathing down my neck and if I make a pigs ear of it I can always, as a last resort, reformat the disk and reinstall at my leisure without having the fear of losing the companies mission critical files and running home to raid my piggy bank, grab my passport and hastily head off to a country outside the UKs legal jurisdiction! I do not profess to begin to understand debugfs yet, but I certain intend to knock up a quick scrap disk I can use in my PC to experiment on for now and the future. I would much rather learn about useful programs like this now, while in a relaxed and fun mood, than desperately straining my brain in a state of sheer panic a few months down the line when I have a real crashed disk infront of me.
Thanks once again for your prompt and extensive help Xsprite.
Ian.
This is a SCSI disk. Open your case and make sure that all the connectors are properly pushed home - including the one on the mmotherboard. BTW I assume you have all the correct terminators on?
On 30-Nov-01 Ian Douglas wrote:
Hi folks,
If I run "e2fsck /dev/sda5" I get the following error:
/dev/sda5 contains a filesystem with errors, check forced: Pass 1: Checking inodes, blocks and sizes Pass 2: Checking directory structure Missing '..' in directory inode 195 Fix <y>? yes Missing '..' in directory inode 196 Fix <y>? yes Pass 3: Checking directory connectivity Unmounted directory inode 195 (/???) Connect to /lost+found <y>? yes /lost+found not found. Create <y>? yes Error creating /lost+found directory (ext2fs_link): No free spacein the directory
I am confused. If I mount /dev/sda5 on /mnt and have a look around it, it all looks ok and if I do a df it tells me there is still plenty of free space on the partition (as I expected): Filesystem: /dev/sda5 1k-blocks: 3958767 Used: 1653871 Available: 2100069 Use%: 44%
Anyone know how I can correct this "lost+found" error?
Ian.
main@lists.alug.org.uk http://www.anglian.lug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Thanks for your helpful suggestion Raphael. Yes you are correct, my problem did relate to a SCSI disk but I had already checked the cables/terminators and everything looked ok physically. However, thanks to the help I received from another ALUG list subscriber on Friday/Saturday, the problem has now been resolved and the disk is now fully functional again (refer to my posts yesterday for explanation). Your point about terminators is however one worth reiterating when dealing with SCSI disks.
Ian.
Raphael Mankin wrote on Sunday, December 02, 2001 7:58 PM
This is a SCSI disk. Open your case and make sure that all the connectors are properly pushed home - including the one on the mmotherboard. BTW I assume you have all the correct terminators on?
-
Ian Douglas -
Raphael Mankin -
xsprite＠bigfoot.com