format/newfs larger external consumer drives

Don whY Don.whY at gmx.com
Fri Jul 24 00:52:06 UTC 2015


On 7/22/2015 2:08 PM, Dieter BSD wrote:
> Don whY asks:
>> So, fsck's effort (and execution *time*) is based *mostly* on inodes?
>
> I don't know about *mostly*, but reducing the number of inodes
> significantly reduced fsck time for me.

OK.  I may try building a filesystem, loading a fixed set of files
(assorted) onto it, then fsck'ing it.  Then, rebuild with a different
block/frag/inode configuration and try again (same file set).  At
the very least, it will be an interesting experiment!

>> In my case, there isn't any real physical room for an internal disk.
>> I'm using Dell FX160's -- they'll support a SATA laptop drive
>
> Assuming that "SATA laptop drive" means 2.5" form factor,
> just add a 6 TB SSD.  (available this month, but the price is
> top secret)

"If you have to ask, then you can't afford it!"  :>

>> The point is to get rid of the piles of CD/DVD media that I've
>> accumulated over the years
>
> Someone must make a jukebox for those.

Sure!  I could have rescued a large 42U unit for "a song" a while
ago.  But, who wants to find space for such a beast when you can
move the entire contents onto 3.5" drives??  (and get true random
access without waiting for a robot!)

>>> I am very tired of having an entire machine panic just because
>>> one disk decided to take a nap.  This is not how you get 5 9s.  :-(
>>
>> Or, power glitches, firmware bugs, etc.
>
> A UPS eats power glitches for breakfast.

UPS's take lots of care and feeding.  :<  I've got a dozen 1500VA
units here.  Seems like I am perpetually replacing batteries,
*somewhere*!  :<

> Firmware is a problem.
> More and more mainboards can have FLOSS firmware, but there is also
> buggy firmware in disks and other devices.
>
> Warren helpfully pointed us to
>
>> http://sourceforge.net/projects/fuse-ufs2/
>
> Thanks, Warren!  Sourceforge was kaput when I tried to check it out.
> I'm hoping that it is a high quality implementation, and, being fuse,
> will solve the kernel panic problem. I plan to look at the filesystem
> regression tests and see if I can think up any additional test cases.

I suspect I can live without this -- especially in the context of
this being a "demo app" just to illustrate what sort of things are
(relatively) easy to do.  Let someone else with "free time" polish
the rough spots!  :>  My plate is already overflowing  :<


More information about the freebsd-hackers mailing list