SUMMARY: insufficient space in super block for rotational layout

Original question:
> 
> Environment:
> 
>     Sun Sparc Solaris 8 Generic_108528-29 on an E250
>     Infortrend EonStor 1.4TB RAID 5, U320 SCSI host connection
> 
> When I go to "newfs" the filesystems, I'm getting
> 
>      Warning: insufficient space in super  block  for  rotational
>      layout     tables    with    nsect    sblock.fs_nsect    and
>      ntraksblock.fs_ntrak.  (File  system  performance   may   be
>      impaired.)
> 
> I've searched and searched, and can find nothing more than what
> "man mkfs_ufs" offers, by way of explanation:
> 
>       Occurs typically on very high  density  disks.  On
>       such  disks,  the  file  system  structure  cannot
>       encode the proper disk layout information, result-
>       ing in suboptimal performance.
> 
> So the question is: Is this really an issue with a RAID 5 storage
> array?  A colleague of mine, explaining what the "rotational layout
> table" is and how it's used, suggests not.  He suggests that, even if
> there would be an impact, it would only affect very large files.
> (Files that would span more than a cylinder group?)  In any event: It
> doesn't appear I can do anything about it.  (Other than shrinking the
> RAID 5 partitions.)

The Resolution:

I did even more digging.  The only answer that came up more than once
was "Solaris doesn't like more than 64 heads."  (I think I was just too
tired and too wired last night for that to have sunk in.)

So off to the office I went.  I re-configured the Infortrend EonStor's
host configuration to tell the host the array had 64 heads (cylinders
ended-up somewhere around 36k and sectors ended-up 255, IIRC) and the
problem was solved.

No more "insufficient space in super block" messages from mkfs_ufs.

As a bonus: No more "num sector(s) in last cylinder group unallocated"
messages, either :).

Fsck'd all the devices after newfs'ing them.  Cloned a couple of the
smaller filesystems over to the new array (using star) and re-fsck'd
and ran a file-by-file compare between source and destination on one of
them.  All appears to be solid.

Thanks to Ric Anderson and Anthony D'Atri for their replies.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.linxnet.com/contact/scform.php>.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers