UNIX for Dummies Questions & Answers

Below there is a sample of ls in the root (/) directory. Does anyone know why the 'lost+found' directory has 8192 in size while it is completely emply????




<pre>
drwxr-xr-x 36 root root 1536 Oct 26 13:31 ./
drwxrwxrwt 7 sys sys 3250 Oct 26 14:20 tmp/
drwxrwxrwx 2 root other 512 Aug 10 18:28 prod/
drwxrwxrwx 2 root other 512 Aug 10 18:29 ort/
drwxrwxrwx 2 root other 512 Mar 19 2001 cdrom/
drwxrwxrwx 2 root other 512 Mar 20 2001 tftpboot/
drwxrwxrwx 2 root root 512 Mar 19 2001 volmgt/
drwxrwxrwx 2 root root 512 Mar 20 2001 TT_DB/
drwxrwxrwx 2 root root 8192 Mar 19 2001 lost+found/
drwxrwxrwx 2 root sys 512 Mar 19 2001 export/
drwxrwxrwx 2 root sys 512 Mar 19 2001 mnt/
drwxrwxrwx 2 root sys 512 Mar 19 2001 sbin/
drwxrwxrwx 4 root root 512 Aug 14 11:04 u04/
drwxrwxrwx 4 root sys 512 Mar 19 2001 devices/
drwxrwxrwx 5 root root 512 Aug 9 16:46 u02/
drwxrwxrwx 6 root root 512 Sep 28 10:43 u01/
drwxrwxrwx 8 root root 512 Aug 22 09:06 u03/
drwxrwxrwx 9 root sys 512 Mar 19 2001 kernel/
drwxrwxrwx 10 root sys 512 Sep 3 16:25 opt/
drwxrwxrwx 11 root sys 3584 Oct 9 14:21 dev/
drwxrwxrwx 18 root sys 1024 Mar 19 2001 platform/
drwxrwxrwx 23 ort clarify 512 Sep 27 09:45 home/
drwxrwxrwx 26 root sys 512 Aug 3 14:52 var/
drwxrwxrwx 31 root sys 1024 Mar 29 2001 usr/
drwxrwxrwx 33 root sys 3584 Oct 26 09:25 etc/
lrwxrwxrwx 1 root root 9 Mar 19 2001 bin -> ./usr/bin/
lrwxrwxrwx 1 root root 9 Mar 19 2001 lib -> ./usr/lib/

</pre>

Does this file keep the inode number instead ??

What about 'xfs_repair'?? Would that number change if I use the above command??

Does the following command surprise you at all?
While sorting the files the 'lost+found' directory stays along with the parent . dir. Is is because the sorting has to do with the inode?

<pre>

(root)11: ls -lusiop|sort
2 4 drwxr-xr-x 36 root 1536 Oct 26 15:06 ../
2 4 drwxr-xr-x 36 root 1536 Oct 26 15:06 ./
3 16 drwxrwxrwx 2 root 8192 Oct 26 14:30 lost+found/
94 2 lrwxrwxrwx 1 root 9 Oct 26 15:06 bin -> ./usr/bin/
95 2 lrwxrwxrwx 1 root 9 Oct 26 15:05 lib -> ./usr/lib/
116 4 -rw------- 1 root 1032 Jul 16 17:20 .cpr_config
373 10 -rw-r--r-- 1 root 4396 Oct 26 14:30 .cshrc
417 2 -rw-r--r-- 1 root 406 Oct 26 13:31 .OWdefaults
418 2 -rw-r--r-- 1 root 912 Oct 26 13:31 .Xdefaults
419 2 -rw-r--r-- 1 root 977 Sep 4 16:06 .desksetdefaults
420 12 -rw-r--r-- 1 root 5161 Oct 26 13:31 .dtprofile
421 2 -rw-r--r-- 1 root 28 Oct 18 14:38 .exrc
422 2 -rw-r--r-- 1 root 38 Oct 3 12:24 .forward_orig
423 0 -rw-r--r-- 1 root 0 Jul 16 17:20 .hushlogin
424 2 -rw-r--r-- 1 root 658 Sep 10 09:55 .login
425 4 -rwxr-xr-x 1 root 1620 Jul 16 17:20 .openwin-init*
426 8 -rw-r--r-- 1 root 3412 Jul 16 17:20 .openwin-menu
427 2 -rwxr-xr-x 1 root 790 Oct 26 14:30 .profile*
428 2 -rw-r--r-- 1 root 871 Jul 16 17:20 .xinitrc
430 2 -rw------- 1 root 64 Jul 16 17:20 .notrhosts
432 2 -rw-r--r-- 1 root 668 Oct 4 13:45 filespace.txt
433 38 -rw-r--r-- 1 root 18912 Oct 4 13:48 corefiles.txt
434 86 -rw------- 1 root 43916 Sep 28 15:30 .sh_history
435 2 drwx------ 4 root 512 Oct 26 12:17 Mail/
437 6 -rw-r--r-- 1 root 2193 Oct 11 15:27 server.log
439 2 -rwxr-xr-x 1 root 764 Sep 10 15:35 .profile.orig*
441 2 -rwxrwxrwx 1 root 438 Oct 11 15:27 profile.org*
445 4 -rwxrwxrwx 1 root 1449 Oct 15 16:16 backup_host*
446 2 -rwxr----- 1 root 386 Oct 11 15:27 test.tq*
452 2 -rwxr-xr-x 1 root 748 Oct 16 15:22 ole.sh*
453 1088 -rw-r--r-- 1 root 548485 Oct 11 15:27 CLFY.055
455 2 -rwxr-xr-x 1 root 768 Sep 28 12:38 start_clarify_netcool_gw.sh*
456 2 -rw------- 1 root 108 Oct 11 15:27 dead.letter
457 6 -rw-r--r-- 1 root 2580 Sep 10 15:42 sybinit.err
458 2 -rw-r--r-- 1 root 872 Oct 9 09:22 .mailrc
461 2 -rw------- 1 root 369 Oct 26 13:32 .TTauthority
463 2 -rw------- 1 root 196 Oct 26 13:32 .Xauthority
11200 2 drwxrwxrwx 26 root 512 Oct 26 13:39 var/
11739 2 drwxr-xr-x 2 root 512 Oct 26 12:17 .hotjava/
22400 2 drwxrwxrwx 23 ort 512 Oct 26 14:56 home/
33600 2 drwxrwxrwx 6 root 512 Oct 26 12:17 u01/
44800 2 drwxrwxrwx 5 root 512 Oct 26 12:17 u02/
56000 2 drwxrwxrwx 8 root 512 Oct 26 12:17 u03/
56078 2 drwxrwxrwx 2 root 512 Oct 26 12:17 sbin/
67200 2 drwxrwxrwx 4 root 512 Oct 26 12:17 u04/
78400 2 drwxrwxrwx 31 root 1024 Oct 26 12:17 usr/
90108 2 drwxrwxrwx 2 root 512 Oct 26 12:17 tftpboot/
90154 2 drwx------ 2 root 512 Oct 26 12:17 DeadLetters/
101483 2 drwxr-xr-x 13 root 512 Oct 26 12:17 .dt/
101498 2 drwxr-xr-x 2 root 512 Oct 26 12:17 tq/
134400 2 drwxrwxrwx 18 root 1024 Oct 26 12:17 platform/
145678 513 dr-xr-xr-x 123 root 262336 Oct 26 15:06 proc/
201667 2 drwxrwxrwx 2 root 512 Oct 26 12:17 mnt/
212860 2 drwxrwxrwx 9 root 512 Oct 26 12:17 kernel/
212861 2 drwxrwxrwx 10 root 512 Oct 26 12:17 opt/
280059 16 drwxrwxrwt 7 sys 3250 Oct 26 13:25 tmp/
302402 8 drwxrwxrwx 33 root 3584 Oct 26 14:30 etc/
380919 2 drwxrwxrwx 2 root 512 Oct 26 12:17 cdrom/
392303 2 drwxrwxrwx 2 root 512 Oct 26 12:17 TT_DB/
392623 2 drwxrwxrwx 2 root 512 Oct 26 12:17 prod/
403821 2 drwxrwxrwx 2 root 512 Oct 26 12:17 ort/
448066 8 drwxrwxrwx 11 root 3584 Oct 26 12:17 dev/
448068 2 drwxrwxrwx 4 root 512 Oct 26 12:17 devices/
470690 1 dr-xr-xr-x 1 root 1 Oct 26 12:17 net/
471055 2 drwxrwxrwx 2 root 512 Oct 26 12:17 export/
471172 1 dr-xr-xr-x 1 root 1 Oct 26 12:17 u/
471173 1 dr-xr-xr-x 1 root 1 Oct 26 12:17 proj/
471174 1 dr-xr-xr-x 1 root 1 Oct 26 12:17 vol/
471175 2 drwxrwxrwx 2 root 512 Oct 26 12:17 volmgt/
total 1931

</pre>

Suggestions ??

Sheesh, where to start?

That ls you did is putting the link count as the first thing on the line. In effect, you sorted on link count.

I've never heard of xfs_repair but it sounds like fsck. The lost+found directory is used by fsck as a place to store inodes that are orphaned. The orphaned files are linked into the lost+found directory with the name being set to the inode number.

With most current filesystems, directories grow but do not shrink. This is exploited by fsck. The lost+found directory has empty slots already allocated. There typically is a script called mklost+found to rebuild it if it is removed.

Since fsck is running and we have located orphaned files, there clearly is file system damage. Under these circumstances, the list of free blocks in the filesystem should not be trusted. That's why lost+found must have space available, fsck cannot safely find a free block at this point in time. One of the last thinks fsck will be is to rebuild the free list. This also simplifies the code required to write fsck.

That was a very good explanation, thanks very much !!

:-)