fsck_ufs a 2TB partition with 256MB RAM stalls

[Peter Jeremy]

On 2011-Jul-07 15:57:52 +0200, Rick van der Zwet <info at rickvanderzwet.nl> wrote:
>I want to build a file server with limited power usage, so I got
>myself an ALIX alix2d13 which has 256MB DDR RAM. I connected a 2TB
>USB2.0 disk to the alix2d13 to be used as storage.
>
>The file system gets corrupted due to power failure, which is likely
>going to happen when running Solar Power in The Netherlands, I cannot
>fix it anymore cause the fsck_ufs never to complete. This actually
>makes sense as the recommendation [1] says ``1TB storage needs 1GB of
>RAM for fsck_ufs''.

The problem is that fsck allocates both per-CG and per-allocated-inode
space (and possibly other space) so running fsck on a large UFS needs
lots of RAM.  I suspect you'll need to find an amd64 box to run the
fsck on but you might be able to get the fsck to complete (very
slowly) by adding plenty of swap (on another disk) and increasing
kern.maxdsiz in loader.conf.

>I can partition my disk in 16 parts of 128GB to work around the
>matter, but I rather keep one large partition.

That's probably the best solution but you could reduce the need to
run fsck by:
- Arrange an "about to run flat" warning from your battery to allow
  clean shutdown.
- Use SU+J (the journal file should remove the need for fsck in almost
  all situations)
- don't fsck on all unclean startups - soft-updates means that it's
  safe (or should be) to mount and continue to use a "dirty" FS -
  the downside is that you may be missing some free space.

If you have ready access to an amd64 box, then a combination of the
above may be workable.

Note that if your disk loses power uncleanly, it's fairly important to
disable the write-cache (or at least do some tests to verify that
synchronous writes make it to the platter before being acknowledged).
If synchronous writes aren't guaranteed to be on-disk then you can't
rely on soft-updates, with or without journalling, and must do full
fsck if the FS is unclean.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110710/eaa01213/attachment.pgp