Consider different xfs formatting options for arbiter brick

[phlogistonjohn]

Kind of issue

Feature request

Description

Currently the xfs file system written for the arbiter brick of an arbiter volume uses the exact same options as a normal brick. As this volume is treated specially it may make sense to format it specially too. We would want to optimize the filesystem for creating directories and inodes at the expense of data (of which there should be little to none).

From a quick skim of the manpage it seems that the option -i maxpct=0 reserves no space for data:

    Setting the value to 0 means that essentially all of  the
    filesystem  can  become  inode blocks, subject to inode32
    restrictions.

Which seems like it would make sense for an arbiter brick. We should investigate if there are any other options we should set for the brick fs as well.

[nixpanic]

@itisravi do you have a recommendation for this?

[phlogistonjohn]

I'd also to make sure @raghavendra-talur is aware of this thread.

[raghavendra-talur]

@phlogistonjohn @nixpanic @itisravi currently

1. we create xfs partitions with 512 bytes inode blocks
2. inode blocks are restricted to only 25% of the filesystem
3. Gluster mainly uses the arbiter brick to store extended attributes.

IIUC, the extended attributes can be stored either in the inode blocks or in the data blocks. That way, we should still be able to consume the brick totally. However, we do need to see if making inode blocks bigger gives us any improvement in performance.

I will do some experiments and get back with perf data, but, I don't think we should run out of inodes or inode blocks before consuming the brick completely.