All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Wang via ltp <ltp@lists.linux.it>
To: Soma Das <somadas1@linux.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] zram: skip exfat on systems with large page size
Date: Sat, 4 Apr 2026 09:14:32 +0800	[thread overview]
Message-ID: <adBl-CJwsLk8i43c@redhat.com> (raw)
In-Reply-To: <20260403165947.9094-1-somadas1@linux.ibm.com>

Thanks for the explanation.

I still think we should go with the -c approach rather than skipping.
A couple of points:

On 1, I don't think this changes the scope of the test. zram01 already
invokes mkfs.$fs as a means to exercise zram, adjusting a parameter so
that mkfs actually succeeds is just making the test work, not turning
it into a filesystem configuration test.

On 2, 25MB with a 64KB cluster size gives roughly 390 clusters, which
is well within exfat's limits. Could you point out a concrete constraint
that would actually fail here? If there isn't one, I'd prefer not to
use a hypothetical concern as justification for skipping.

On the TCONF, reporting TCONF here would make it look like exfat on
zram is fundamentally broken on 64K-page systems, when in reality it
works with a one-line change. That is a false negative we should
avoid in a test suite.

Please send a v2 with the -c approach.

On Fri, Apr 03, 2026 at 04:59:47PM +0000, Soma Das wrote:
> On Fri, Apr 03, 2026 at 09:47:33AM +0800, Li Wang wrote:
> > Or, can we specify the sector size with 'mkfs.$fs -c $page_size'
> > when detecting a large pagesize system?
> 
> Thanks for the review.
> 
> Using mkfs.exfat -c $page_size would technically work, but I avoided
> it because:
> 
> 1. zram01 tests zram behaviour, not filesystem configuration -- using
>    a non-default cluster size feels out of scope.
> 2. The cluster size must be valid for the disk size (only 25MB here),
>    so large cluster sizes could hit additional constraints.
> 
> Skipping with TCONF honestly reflects that default exfat tooling does
> not support this hardware configuration, which is useful signal.
> 
> Happy to send a v2 with the -c approach if you prefer.
> 
> Thanks,
> Soma
> 

-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-04-04  1:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02  8:12 [LTP] [PATCH] zram: skip exfat on systems with large page size Soma Das
2026-04-03  1:47 ` Li Wang via ltp
2026-04-03 16:59   ` Soma Das
2026-04-04  1:14     ` Li Wang via ltp [this message]
2026-04-04 17:20       ` Soma Das

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adBl-CJwsLk8i43c@redhat.com \
    --to=ltp@lists.linux.it \
    --cc=liwang@redhat.com \
    --cc=somadas1@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.