All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: qemu-devel@nongnu.org, Will Cohen <wwcohen@gmail.com>,
	Greg Kurz <groug@kaod.org>,
	Michael Roitzsch <reactorcontrol@icloud.com>,
	Keno Fischer <keno@juliacomputing.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net,
	Latchesar Ionkov <lucho@ionkov.net>
Subject: Re: [RFC PATCH] 9p: case-insensitive host filesystems
Date: Sat, 23 Apr 2022 04:57:40 +0900	[thread overview]
Message-ID: <YmMItCb97KqegQw5@codewreck.org> (raw)
In-Reply-To: <1757498.AyhHxzoH2B@silver>

Christian Schoenebeck wrote on Fri, Apr 22, 2022 at 08:02:46PM +0200:
> So maybe it's better to handle case-insensitivity entirely on client side? 
> I've read that some generic "case fold" code has landed in the Linux kernel 
> recently that might do the trick?

I haven't tried, but settings S_CASEFOLD on every inodes i_flags might do
what you want client-side.
That's easy enough to test and could be a mount option

Even with that it's possible to do a direct open without readdir first
if one knows the path and I that would only be case-insensitive if the
backing server is case insensitive though, so just setting the option
and expecting it to work all the time might be a little bit
optimistic... I believe guess that should be an optimization at best.

Ideally the server should tell the client they are casefolded somehow,
but 9p doesn't have any capability/mount time negotiation besides msize
so that's difficult with the current protocol.

-- 
Dominique | Asmadeus

WARNING: multiple messages have this Message-ID (diff)
From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
	Greg Kurz <groug@kaod.org>,
	Keno Fischer <keno@juliacomputing.com>,
	Michael Roitzsch <reactorcontrol@icloud.com>,
	Will Cohen <wwcohen@gmail.com>,
	netdev@vger.kernel.org, v9fs-developer@lists.sourceforge.net
Subject: Re: [RFC PATCH] 9p: case-insensitive host filesystems
Date: Sat, 23 Apr 2022 04:57:40 +0900	[thread overview]
Message-ID: <YmMItCb97KqegQw5@codewreck.org> (raw)
In-Reply-To: <1757498.AyhHxzoH2B@silver>

Christian Schoenebeck wrote on Fri, Apr 22, 2022 at 08:02:46PM +0200:
> So maybe it's better to handle case-insensitivity entirely on client side? 
> I've read that some generic "case fold" code has landed in the Linux kernel 
> recently that might do the trick?

I haven't tried, but settings S_CASEFOLD on every inodes i_flags might do
what you want client-side.
That's easy enough to test and could be a mount option

Even with that it's possible to do a direct open without readdir first
if one knows the path and I that would only be case-insensitive if the
backing server is case insensitive though, so just setting the option
and expecting it to work all the time might be a little bit
optimistic... I believe guess that should be an optimization at best.

Ideally the server should tell the client they are casefolded somehow,
but 9p doesn't have any capability/mount time negotiation besides msize
so that's difficult with the current protocol.

-- 
Dominique | Asmadeus


  reply	other threads:[~2022-04-22 22:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 18:02 [RFC PATCH] 9p: case-insensitive host filesystems Christian Schoenebeck
2022-04-22 19:57 ` Dominique Martinet [this message]
2022-04-22 19:57   ` Dominique Martinet
2022-05-23 17:59   ` Christian Schoenebeck

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=YmMItCb97KqegQw5@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=ericvh@gmail.com \
    --cc=groug@kaod.org \
    --cc=keno@juliacomputing.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=netdev@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=reactorcontrol@icloud.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=wwcohen@gmail.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.