Benchmark: Gitaly on XFS filesystem

Objective

Benchmark Gitaly on XFS vs ext4 using the framework from #6732. Provide tuning guidance and production recommendation.

Scope

• Filesystems: XFS (primary), ext4 (baseline)
• Workloads: The current mix of RPCs defined in master's k6-benchmark.js is a minimum workload that needs to be run. If additional workloads with different RPCs need to be run, start another report.
• Test with and without transactions

Setup

1. Environment: one node with two dedicated block devices
2. Format: Device A (XFS), Device B (ext4)
   • Modify the metadata_startup_script script of terraform's google_compute_instance to automate the formatting of filesystems to xfs.
3. Mount: Document all mount options used
4. Framework: Use #6732 benchmark suite with standardized datasets

XFS defaults

meta-data=/dev/device            isize=256    agcount=4, agsize=3277258 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=13109032, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=6400, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Reference

XFS Tuning Matrix

• agcount variation
• Log config: logbsize, logbufs variations
• Features: reflink ON to take advantage of Copy on Write to optimize data handling
• Mount options: noatime vs relatime, barrier settings, discard vs fstrim

Documentation Requirements

• Hardware specs (CPU, RAM, storage, RAID/LVM)
• Kernel/OS version, I/O scheduler
• Complete mkfs.xfs and mount options
• Filesystem layout

Deliverables

• Reproducible benchmark results using #6732 framework
• Performance comparison tables/plots
• Analysis of the benchmarks

Quality Assurance

• Consistent cache state between runs (drop_caches) . Since Linux keeps file data and metadata in RAM, without clearing page caches, inodes, later runs may be much faster since it is served from RAM instead of from disk