UFS Fsck complain about "No space in lost+found directory"

the point is: there is NOT such a directory in the file system!

So why this happen and how I can fix the problem?

Code:
UNREF DIR I=451508 OWMNER=root MODE=40755
SIZE=2560 MTIME=May 16 18:45 2018
RECONNECT? yes

SORRY. NO SPACE in lost+found DIRECTORY
UNEXPECTED SOFT UPDATE INCONSISTENCY
As I said, there is NO lost and found directory and the layout of this disk is this one:

Code:
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0s1a    496M    204M    252M    45%    /
devfs          1,0K    1,0K      0B   100%    /dev
/dev/da0s1e    1,9G    704K    1,8G     0%    /tmp
/dev/da0s1f     34G     24G    7,8G    75%    /usr
/dev/da0s1d    2,9G    2,0G    670M    76%    /var
procfs         4,0K    4,0K      0B   100%    /proc
linprocfs      4,0K    4,0K      0B   100%    /usr/compat/linux/proc
fdescfs        1,0K    1,0K      0B   100%    /dev/fd
So, as you can see, there is space on / to eventually create lost+found.

It as to be said that, even if the disk si marked dirty, it boot and it works fine. Then I don't know how safe it could be to work on a system presenting this behaviour.

What can I do? And if I do clone the disk on a new one, could still have this problem?

How fix it?
 
What are you trying to do anyway?

Running fsck manually on the root filesystem? So what filesystem are you using on it? Also: what FreeBSD version are you running?

I almost get the impression that you're trying to use a Linux fsck to repair another filesystem.
 
the point is: there is NOT such a directory in the file system!

So why this happen and how I can fix the problem?

Code:
UNREF DIR I=451508 OWMNER=root MODE=40755
SIZE=2560 MTIME=May 16 18:45 2018
RECONNECT? yes

SORRY. NO SPACE in lost+found DIRECTORY
UNEXPECTED SOFT UPDATE INCONSISTENCY
As I said, there is NO lost and found directory and the layout of this disk is this one:

Code:
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0s1a    496M    204M    252M    45%    /
devfs          1,0K    1,0K      0B   100%    /dev
/dev/da0s1e    1,9G    704K    1,8G     0%    /tmp
/dev/da0s1f     34G     24G    7,8G    75%    /usr
/dev/da0s1d    2,9G    2,0G    670M    76%    /var
procfs         4,0K    4,0K      0B   100%    /proc
linprocfs      4,0K    4,0K      0B   100%    /usr/compat/linux/proc
fdescfs        1,0K    1,0K      0B   100%    /dev/fd
So, as you can see, there is space on / to eventually create lost+found.

It as to be said that, even if the disk si marked dirty, it boot and it works fine. Then I don't know how safe it could be to work on a system presenting this behaviour.

What can I do? And if I do clone the disk on a new one, could still have this problem?

How fix it?
Hi and ty for your reply. No, nothing esoteric. After a crash filesystem went dirty. It dropped me in single user mode to repair using the internal freebsd fsck and I had that output from one of the partitions, repeated many times, and invite me to run fsck forever to always complain about lost+found full.

Even if it wont and can clear the dirty bit on the FS, I can boot and run the system in normal mode apparently without any problem. A crc check on the installed base in the system said everything is ok.

As simple as this on a brand new updated 11.2-RELEASE x86 machine (still old 32 bit install).

No Linux involved.
 
What partitioning scheme do you use? I'm assuming MBR but your partition devices look somewhat outdated to me. Did you by any chance create a freebsd partition type ('BSD disklabel') in which you added the several slices? Perhaps from upgrading a server over several versions?

I'm not fully sure, but it could explain the problems you've been getting. Depending on the way the whole thing was set up of course.

What happens if you try to boot from a rescue system and then perform the fsck? Could you share the output from gpart show /dev/da0?
 
ShelLuser The partition list gives away the partitioning scheme immediately, you can't really have da0s1a on a GPT partitioned disk.

And yes, that looks like very old partitiioning with very small root partition that just barely can hold the necessary files. High time to re-install from scratch.
 
Hi Kpa and thank you for your reply. No need to repartition and less to reinstall (this machine is up and upgrade from the times of FreeBSD 8 and it works like a charm! For me this is the sense to use FreeBSD, lotsa uptime, very few reboots), or not my priority! Everything is fine like that, but the problem I have and I explained in this thread is what I would solve. The fault occurred after a crash related with some hardware upgrade (more memory with different timing from the previous to speed up multitasking file transfers). I didn't take anything in consideration before turn on the upgraded machine so it crashed! After the crash, I fixed the hardware problem and now I do have this annoying disk problem. I just ask how to fix it, not to change this venerable server very impoirtant in my environment, up 24h day with pretty much no downtime before this crash for like 10 years or so (it is the reason becouse I do choose FreeBSD for this tasks).

I may considering to upgrade to a new disk maybe expanding the / root partition and the /usr partition becouse the other partitions are pefectly fine like that. I f I do that I will never reinstall, just dd copy any partition on the new disk a expand it. And If I do that, I want to do pretty much everything "live" without any downtime.

For now if you and/or someone with the right knowledge want help me to solve the topic on this thread, also for my personal learning curve, I could be satisfied!

Again thank you in advance

PS;: the problem is related with partition da0s1f, exactly the /usr partition on the disk. The other partitions are clean and with no problem at all. Just da0s1f is dirty then it works perferctly, then I'm not sure if it will with this problem for long.
 
No offense but it sounds like you're planning on following a recipe to disaster. I also can't help wonder if you tried this trick before (using dd to expand your partition) because that could definitely be a possible cause for what is happening here.

Thing is, the old partitioning scheme worked, it still works, but there have been several improvements over time. Amongst which the GPT scheme. Nothing wrong perse to stick with what you have, but when it comes to upgrading and such then it makes more sense to eventually also adapt to the new standards.

For example security wise: in your current setup any specific damage to the freebsd type partition itself could result in your entire system becoming inaccessible. That kind of risk no longer applies to current partitioning standards where every filesystem also uses its own physical partition.
 
Resizing and growing partitions and disls without loosing data is totally supported by FreeBSD, see Handbook, 17.9.

I did it many times on other machines with complete satisfaction and success and no problems at all..

I just never did it with a dirty partition like my da0s1f partition of this machine that is also the topic of this thread.
 
How I fixed it. NOT solved, becouse my original question is still unanswered. I never figured how to resolve that original issue. But... I fixed it without a lot of effort, and virtually with no downtime. That is what especially count to me: do not spend a lot of time maintinng the machiine and have the machine serving contents like it shoiuld do and always did in the last ten years or so, on this modest, old hardware).

So I connected a USB drive to the system. Formatted a partition in UFS, formatted it with newfs, and lively, with the machine up and running doing it's job, I did a copy with the -a option to the whole content of the dirty partition object of this thread from the /usr partition to the new formatted usb drive partition. The copy went perfectly fine (except for the socket file part of the live session active in that moment, then not a big deal considering those are like temporary files in homes folders).

At that point, still with the machine up and serving, I did something pretty much "hardcoire": I reformatted (using newfs /dev/da0s1f) the da0s1f partition on the running machine (!!!) and saw nothing crashed. The active programs loaded in volatile memory still worked after this move and what I needed to use just was a terminal to copy back the files to the reformatted /usr on the system drive from the usb drive. Copy back with -a served perfectly again.

To avoid any crash (and possible data corruption) I avoided to test what I did without rebooting the machine, also if I were tempted. So I rebooted the machine avoiding even the single user mode to check the new reformatted partition (to be up and running as fast as I can) and I've been straight ahead in OS and my KDE interface (I'm a KDE long time user and I do use a streamlined configuration of KDE even on server machines!). Every script, everything started perfectly fine, the socket files in the user directory went smoothly recreated and the result of fsck on the reformatted and former offending partition (da0s1f) is now:

Code:
<piggy@freebsd112>/usr/ports # fsck /dev/da0s1f
** /dev/da0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
995185 files, 7227392 used, 1696215 free (5951 frags, 211283 blocks, 0.1% fragmentation)
Now the machine has a two days uptime and everything is back to normal. Total downtime (less than TWO minutes!!! (thumbs up!)

I do not tag this post with solved becouse it asctually isn't considering I used a workaround, then the original post is not solved. And also on Google I found some referencies at this same error not solved, so it seems not a usual problem, then sure an annoying one and no real expert seems able to resolve it. So this workaround could be usefull for someone in my same situation or so.
 
Back
Top