Softupdates not preventing lengthy fsck

[Scott Long]

Kris Kennaway wrote:
> On Tue, Apr 12, 2005 at 12:51:12PM -0700, Don Lewis wrote:
> 
>>On 12 Apr, Scott Long wrote:
>>
>>>Kris Kennaway wrote:
>>
>>>>I can take a transcript of the entire fsck next time if you like :-)
>>>>(it ran for more than 5 hours on the 24G drive and was still going
>>>>after I went to bed)
>>>>
>>>>Kris
>>>
>>>Don might not know that your workload involves creating and deleting
>>>full ports/ trees repeatedly, and those trees contain hundreds of
>>>tousands of inodes each.
>>
>>I suspected that, especially given the inode timestamps in the partial
>>transcript.
> 
> 
> Actually the ports trees are not recreated (they're mounted via nullfs
> and accessed read-only), and the files that are created are due to
> building, installing and uninstalling of ports on a plain old ufs2.
> It's still a lot of files though.
> 

Sorry, from the files that I tried to repair on my system it looked like
there was a ports tree removal involved.

> 
>>>If there is a reference count leak and those
>>>deletions aren't ever being finalized, then there would be a whole lot
>>>of work for fsck to do =-)  Might also explain why disks have been
>>>unexpectedly filling up on package machines (like mine).
>>
>>Sounds likely.  When the disk starts looking unexpectedly full, can you
>>unmount the file system or does the attempt fail with and EBUSY error?
>>What happens if you fsck the file system after it has been unmounted?
>>Are snapshots being used?
> 
> 
> Scott was the one who tried to repair the system after this happened,
> so he can probably answer it better.  I'm certainly not using
> snapshots myself.
> 
> Kris
> 

I gave up after lost+found filled up (literally) with directory inodes
that couldn't be removed.  Using clri on them only made fsck more upset.
That filesystem is still hanging around on a disk that is powered down
now, bit I'd be happy to ship it to someone for a post-mortem if
desired.  It's a SCSI disk, though.

Scott