fksck reports ZERO LENGHT DIR after a fresh restore

[ghostwolf59]

Hi,
Have dragged on trying to resolve freenas 8.3 reporting "unreadable sectors" on some of my disks where I finally decided to clob my source and reformat one disk before performing a restore from a previoud backup.

The backup is done via rsync resulting on that the destination disk file structure holds the source named disk name as the root folder
After reformatting my source disk I then did a rsync back from backup to source resulting in that the destination disk folder structure now have the original disk name as it's root folder - effectively breaking my CIFS, but where I can see that future rsync's would result in a naming along <diskname>/root folder(now same as diskname)/folders/...

After my rscync from backup to destination drive (source) I then moved the content to properly reflect the original disk (in effect moving all content under the "named disk" folder to the disk root

Looks ok and reports the same size etc.

When I run a fsck on the refreshed source I now get a ZERO LENGHT DIR during step 4...
** /dev/ufs/STORE04 (NO WRITE)
** Last Mounted on /mnt/STORE04
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
ZERO LENGTH DIR I=112716800 OWNER=root MODE=40777
SIZE=0 MTIME=Apr 21 20:34 2013
CLEAR? no

No idea what it;'s pointing to or how to resolve this.

Any ideas ?

cheers

 

[joeschmuck]

Have you tried a Google search for this problem? Here is what I came up with and there is more out there... http://techpubs.sgi.com/library/dynaweb_docs/0630/SGI_Admin/books/IA_DiskFiles/sgi_html/apa.html

Since it sounds like you have this data on a separate drive, I'd say yes to clear and then examine my data to see if it's in tact. You could of course create a file which lists all the directories before you fix it and then after and compare to see what was removed.

Also, did you run fsck on the drive after you restored it but before you moved the files around?

 

[jgreco]

There may be a corrupt directory. However, if there were any lost files in it, they're very likely to end up in lost+found in the filesystem's base directory, so data loss is unlikely. fsck is actually complaining about the invalidity of the directory, so you probably won't see the directory (certainly not any contents) and at worst you might panic the machine trying to futz with it, so proceed accordingly. There is no easy way to ascertain what files were in the directory previously. However, it is completely safe to do a "fsck -n /dev/ufs/STORE04" to see how bad fsck thinks it all is.