problem mounting from flash [Invalid sectorsize] [g_vfs_done() ?error=22]

[Bruce Evans]

On Mon, 8 Nov 2010, Oliver Fromme wrote:

> Monthadar Al Jaberi <monthadar at gmail.com> wrote:
> > I dont know if I am asking on the wrong place. But it has todo with
> > filesystem and onboard flash (16MB) on a RouterStation Pro board.
> >
> > I am running a FreeBSD Current 201010, with the kernel configuration
> > file specified in /usr/src/sys/mips/conf/AR71XX with device
> > geom_redboot.
> >
> > but I get this error when I try to mount from flash:
> > mount /dev/redboot/fs /var/fs
> > mount: /dev/redboot/fs Invalid sectorsize 65536 for superblock size
> > 8192: Invalid argument
> >
> > So I guessed it has todo with the flash configured in 64k sectors
> > according to the boot output.
> > ...
> > mx25l0: <M25Pxx Flash Family> at cs 0 on spibus0
> > mx25l0: mx25ll128, sector 65536 bytes, 256 sectors
> > ...
>
> Historically UFS/FFS supports only 512 bytes per sector.
> I think it was patched at some point in the past to support
> 2048 bytes per sector, too, which is used by some MOD media
> and DVD-RAM.  I'm pretty sure it does _not_ support 65536
> bytes per sector (someone please correct me if I'm wrong).

Maybe 25 years ago, but in Net2/ 20 years ago ffs doesn't really
even use sectors.  It just has a buggy superblock probe which
prevents it determining its correct i/o size when that size
exceeds SBLOCKSIZE = 8192.

>
> > So I just tried to change SBLOCKSIZE from 8129 to 65536 in
> > /usr/src/sys/ufs/ffs/fs.h, but then I got this error:
>
> That won't work.  The media sector size is a hard limit;
> the driver will refuse to read or write anything that is
> not aligned to the media sector size.  Changing the size
> of the super block (SBLOCKSIZE) won't help much.
>
> > mount /dev/redboot/fs /mnt/fs
> > g_vfs_done():redboot/fs[READ(offset=8192, length=65536)]error = 22
> > mount: /dev/redboot/fs : Invalid argument
>
> The UFS code tries to read the super block at offset 8192,
> which is not aligned correctly (it's not a multiple of the
> sector size).

The ffs code (and also utility code like ffs_fsck) bogusly aborts the
search on the first i/o error.  Otherwise, changing just the size should
work for ffs2.

Changing both the offset and the size should work.  I think it might
just work for ffs2 once you recompile all utilities using the
changed SBLOCKSEARCH and SBLOCKSIZE.  The change will necessarily
break ffs1: from ffs/fs.h:

%  * Depending on the architecture and the media, the superblock may
%  * reside in any one of four places. For tiny media where every block 
%  * counts, it is placed at the very front of the partition. Historically,
%  * UFS1 placed it 8K from the front to leave room for the disk label and
%  * a small bootstrap. For UFS2 it got moved to 64K from the front to leave

It can't be at 8K if the media sector size is 8K.  Except, with more changes
to the probe, perhaps it can be (e.g., always start by reading 128K at offset
0, and check what is at various offsets within the 128K.  This covers all
the usual cases in 1 i/o).

%  * room for the disk label and a bigger bootstrap, and for really piggy
%  * systems we check at 256K from the front if the first three fail. In
%  * all cases the size of the superblock will be SBLOCKSIZE. All values are

Actually, the size of the superblock will never be SBLOCKSIZE.  It will
always be sizeof(struct fs), which is about 1500.  SBLOCKSIZE is just the
i/o size used in buggy probes for the superblock.

%  * given in byte-offset form, so they do not imply a sector size. The
%  * SBLOCKSEARCH specifies the order in which the locations should be searched.
%  */
% #define SBLOCK_FLOPPY	     0

I don't remember this ever working.  Floppies normally start with a 512-byte
boot sector.  Thus the superblock cannot start a 0 for a normal floppy,
and I don't remember anything ever supporting sufficiently abnormal floppy
for this to work.  (My kernel has incomplete support for this putting the
superblock at offset 512, involving reducing MINBSIZE to 512 and using
512-blocks for everything.  Everything works except superblock size and
probing issues.  The superblock should end up beginning in the first
fs_bsize block after the boot blocks (normally 512, but could be 0 with
more work).

% #define SBLOCK_UFS1	  8192
% #define SBLOCK_UFS2	 65536
% #define SBLOCK_PIGGY	262144
% #define SBLOCKSIZE	  8192
% #define SBLOCKSEARCH \
% 	{ SBLOCK_UFS2, SBLOCK_UFS1, SBLOCK_FLOPPY, SBLOCK_PIGGY, -1 }

Try changing SBLOCK_UFS1 to 65536 too.  Obviously this breaks the normal
ffs1 case.  Better, try changing only SBLOCKSIZE and not aborting on i/o
error.

> I think UFS is not the right file system to put on a flash
> media that has 256 sectors of 65536 bytes.  In theory you
> could insert a translation layer that converts 512-byte
> access to 65536-byte access (requiring a read-modify-write
> operation when writing).  Maybe gnop(8) can do this, it
> has a sector size option, but I haven't tried it.  Anyway,
> that would be extremely inefficient.

Hmm, 256 sectors is small.  It might have negative space for
data after using > 256 ssectors for metadata.

Bruce