Re: [PATCH blktests] common/xfs: ignore the 32M log size during mkfs.xfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Oct 19, 2022 / 19:18, Chaitanya Kulkarni wrote:
> On 10/19/22 07:19, Eric Sandeen wrote:
> > On 10/19/22 1:16 AM, Chaitanya Kulkarni wrote:
> >> On 10/18/22 22:12, Yi Zhang wrote:
> >>> The new minimum size for the xfs log is 64MB which introudced from
> >>> xfsprogs v5.19.0, let's ignore it, or nvme/013 will be failed at:
> >>>
> >>
> >> instead of removing it set to 64MB ?
> > 
> > What is the advantage of hard-coding any log size? By doing so you are
> > overriding mkfs's own best-practice heuristics, and you might run into
> > other failures in the future.
> > 
> > Is there a reason to not just use the defaults?
> > 
> 
> I think the point here to use the minimal XFS setup.
> 
> Does default size is minimal ? or at least we should document
> what the size it is.

As far as I read `man mkfs.xfs`, it is not minimal. It changes depending on the
filesystem size.

To have minimal XFS setup, do we need to care other parameters than log size?
I'm looking at 'man mkfs.xfs' and it mentions data section size and some other
size related options.

Two more questions have come up in my mind:

- Did we have nvme driver or block layer issues related to xfs log size in the
  past? If so, it is reasonable to specify it.

- When we see failures of xfs user test cases (nvme/012,013,035), is xfs log
  size useful to debug?

-- 
Shin'ichiro Kawasaki



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux