panic ufs_dirrem: bad link count 2 on parent error

hdc

hdc

Hi

I had copied /usr folder from one disk (mounted as /) to another disk (mounted as /usr now).

The old /usr folder was renamed to /usr.b.

So far the new /usr folder is working fine. I am removing the /usr.b folder from / disk.

Here is the information of disks:

Code: 
/dev/ada0p2     19G    9.0G    8.2G    53%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/da0p1      19G    6.8G     11G    38%    /usr
FreeBSD version: 11.0-RELEASE-p12

The problem happened while I remove the /usr.b.

the error message from system is
Code: 
panic ufs_dirrem: bad link count 2 on parent
While this error message displayed, the system frozen and I have to reboot it.

I have tried to do following:

1. boot to single user and run fsck. after that 2 files added to /usr/lost+found. but problem is not solved.

2. delete folders / files one by one. Seems the folder /usr.b/ports/www/quickie is the problem.
I had removed all other files in /usr.b and all files&folders under /usr.b/ports/www/quickie but while try to remove the folder quickie could make problem.

Please suggest.
 
When you run several time fsck in single user mode and errors still occur that means your filesystem is definitively dead.
It is as simple as that. Just ensure that home data are safe, and rebuild your system.

If you can, switch to the more reliable ZFS, if you can't, set up UFS + GJournal

I assume you are using UFS with soft update and/or UFS Journaling, this is outdated and this is frankly a real crap.
UFS Journaling can't sustain any comparison with NTFS or Ext4 journaling. This is as this thing was useless.

I also encountered in the past UFS file systems corruptions, loosing sometimes full systems, apart of ZFS, there is only one remedy if you want to keep use UFS :

G J O U R N A L (for internal drives)

Note that there is no unbreakable filesystems, including ZFS.
Generally, if a system crashes repeatedly, it always comes a point where even the strongest filesystem gives up and is unable to recover properly the system.

Generally when I find that lost+found is not empty in my root filesystem I rebuild and reinstall all the world with a brand new fresh download of /usr/src.

Indeed, if something is missing or corrupt in /usr/src, this can lead to a corrupt FreeBSD world building, this is the reason why one should re-download a brand new /usr/src using subversion or copying it from a safe source.

For example you can get the updated 11.1 source to the latest security patches (release engineering) :

Code: 
svn co https://svn0.us-west.freebsd.org/base/releng/11.1 /usr/src
svn update /usr/src

And now you can rebuild and reinstall world

Code: 
cd /usr/src
make buildworld
make installworld

Keeping your old /etc folder, it is generally not necessary to repopulate config files folder, but if you have a doubt use mergemaster. Same remark for kernel, eventually rebuild and reinstall the kernel.

If lost+found is not empty, generally one can't reallocate theses files, that simply means something will be missing somewhere in the FreeBSD system.

Since I use GJournal, such thing doesn't happen anymore except in cases of some severe hardware failures.

UFS + GJournal slow down a little the filesystem but offer a real enterprise class reliability, forget soft update and UFS Journaling, or only use them for hot swappable devices.
 
Last edited:
Do you have any comparison of UFS + GJournal vs ZFS resource consumption and performance? I'm interested in having a reliable simple desktop system for home use. I had data losses when using UFS+SUJ after power losses or unclean shutdowns. With ZFS I had a more robust system, but at the expense of more resources and degraded performance. Do you think UFS + GJournal would be a better fit for my usage?
 
I had this problem and here is how I solved it.
I think that the default option to create a unique UFS root partition for all at installation is bad. I perform my system installation with traditional partitioning like this :
Code: 
# Device           Mountpoint   FStype      Options   Dump   Pass#
/dev/gpt/gpswap    none         swap        sw          0       0
/dev/gpt/gprootfs  /            ufs         rw          1       1
/dev/gpt/gptmpfs   /tmp         ufs         rw          2       2
/dev/gpt/gpusrfs   /usr         ufs         rw          2       2
/dev/gpt/gpvarfs   /var         ufs         rw          2       2
/dev/gpt/gphomefs  /usr/home    ufs         rw          2       2
That way, in case of power loss or system crash, the system will reboot with gprootfs clean because it is not written very often. So if other partitions are not marked CLEAN, background fsck will run and automatically repair it.
I usually use 'soft updates journaling' only for my big '/dev/gpt/gphomefs' partition to recover faster, but disable journaling on other partitions to perform live dump of the system with snapshots.
 
The underlying problem is that you obviously just cp all content from /usr without taking care of preserving links, suid and whatever.

If that's the case, then your new /usr folder would be broken and useless.

There are possibly hard- or softlinks in /usr.b that still refer with their full path to files /usr/... which now is on a seperate filesystem.

It's just a guess but it would match your error and the system freeze. It might have confused journaling as well.

If I where you I would start over...

cp -p might have reduced the destruction in /usr a little, but the best options would have been tar, or my all-time-favorite rsync.
 
k.jacker said:
The underlying problem is that you obviously just cp all content from /usr without taking care of preserving links, suid and whatever.

If that's the case, then your new /usr folder would be broken and useless.

There are possibly hard- or softlinks in /usr.b that still refer with their full path to files /usr/... which now is on a seperate filesystem.

It's just a guess but it would match your error and the system freeze. It might have confused journaling as well.

If I where you I would start over...

cp -p might have reduced the destruction in /usr a little, but the best options would have been tar, or my all-time-favorite rsync.
Click to expand...

The old /usr folder was copied by tar to new disk. the new /usr is working fine no any problem.
the only folder I have problem to delete is /old usr/ports/www/quickie, which is empty folder now and seems no any link to other folders.
 
Ok, then it's true what Wozzeck.Live said. You can't delete the folder
because there is a problem with the filesystem or disk.
If fsck cant't fix it I recommend backup your data.
 
You must log in or register to reply here.
Back
Top