On 6/13/13 7:40 PM, Dave Chinner wrote:
>>> > > + The sunit and swidth parameters specified must be compatible
>>> > > + with the existing filesystem alignment characteristics. If
>>> > > + the filesystem was not created with data alignment
>>> > > + constraints, then it may be impossible to set a valid sunit
>>> > > + (and hence swidth) value. In general, that means the only
>>> > > + valid changes to sunit are increasing it by a power-of-2
>>> > > + multiple. Valid swidth values are any integer multiple of a
>>> > > + valid sunit value.
>> > now I'm confused. It's only relevant to a filesystem w/ geometry
>> > specified, but if it wasn't specified, it may be possible . . . ?
>> > And if nothing was specified (i.e. 0 su/sw) then we can only increase
>> > that 0 by a power of 2?
>>> > > + For filesystems that have existing data alignment values on
>>> > > + disk (i.e. specified by mkfs), any new valid values passed
>>> > > + in as mount options will overwrite the values stored on
>>> > > + disk. Hence this mount option does not need to be specified
>>> > > + for every mount operation in this case.
>> > so I think this all needs to clarify whether it works on filesystems
>> > w/o existing geometry, or not. And "why you might want this" would
>> > be helpful too.
> It's obviously too complex to explain everything in a short "what"
> description. I suspect that the best thing to do here is simply
> document it as a method of changing alignment for a device that has
> changed geometry such as a adding a disk to a MD RAID5 device. I'm
> going to drop any reference to sunit/swidth being zero because that
> case was a hack for fixing a CXFS client bug.
Ok, fair enough on the what not why.
But FWIW, even if we aren't saying why, just what, the docs seem
It talks about existing geometry being required for this option, but also
says what happens if it's not.
If you drop that part, then that sounds good.