On Fri, 26 May 2017 10:52:04 -0400, Allan Streib wrote: > Note the "page size" is different. On the Dell R710 the message says > "page size 65536" which is one higher than 0xffff, which seems like a > red flag? The "upper" and "lower" fields look to be of type indx_t which > is defined as a uint16_t, but in the bt_head struct, psize is a > uint32_t. So the line > > mp->page->upper = bt->head.psize; > > Is going to result in mp->page->upper being zero, if bt->head.psize is 65536. > > I don't understand why the R710 has a different behavior than my desktop > machine, but that's what I'm seeing.
I can explain that. The page size is being set based on the file system block size. On your desktop this is 16384 which you can verify by running the dumpfs command on the filesystem. You'll see something like this: magic 11954 (FFS1) time Fri May 26 06:54:56 2017 id [ 57ffcc69 89ea6f31 ] cylgrp dynamic inodes 4.4BSD fslevel 3 ncg 6 ncyl 6 size 526112 blocks 516263 bsize 16384 shift 14 mask 0xffffc000 fsize 2048 shift 11 mask 0xfffff800 frag 8 shift 3 fsbtodb 2 ... However, the R710 probably has a larger file system with bigger blocks. If it is FFS2 it will look something like this: magic 19540119 (FFS2) time Fri May 26 09:03:51 2017 superblock location 65536 id [ 53f23555 9ac85182 ] ncg 561 size 234374284 blocks 232529698 bsize 65536 shift 16 mask 0xffff0000 fsize 8192 shift 13 mask 0xffffe000 frag 8 shift 3 fsbtodb 4 ... Either indx_t needs to be changed to uint32_t or an upper bound needs to be placed on psize, perhaps 0x7fff. I'm not familiar enough with that code to say which is better. - todd
