[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210120143515.v2vgyhcxrhnnng6r@Air-de-Roger>
Date: Wed, 20 Jan 2021 15:35:15 +0100
From: Roger Pau Monné <roger.pau@...rix.com>
To: Arthur Borsboom <arthurborsboom@...il.com>
CC: <linux-kernel@...r.kernel.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
"Stefano Stabellini" <sstabellini@...nel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Jens Axboe <axboe@...nel.dk>, <xen-devel@...ts.xenproject.org>,
<linux-block@...r.kernel.org>
Subject: Re: [PATCH v2] xen-blkfront: allow discard-* nodes to be optional
On Wed, Jan 20, 2021 at 03:23:30PM +0100, Arthur Borsboom wrote:
> Hi Roger,
>
> I have set up a test environment based on Linux 5.11.0-rc4.
> The patch did not apply clean, so I copied/pasted the patch manually.
>
> Without the patch the call trace (as reported) is visible in dmesg.
> With the patch the call trace in dmesg is gone, but ... (there is always a
> but) ...
>
> Now the discard action returns the following.
>
> [arthur@...t-arch ~]$ sudo fstrim -v /
> fstrim: /: the discard operation is not supported
>
> It might be correct, but of course I was hoping the Xen VM guest would pass
> on the discard request to the block device in the Xen VM host, which is a
> disk partition.
> Any suggestions?
Hm, that's not what I did see on my testing, the operation worked OK,
and that's what I would expect to happen in your case also, since I
know the xenstore keys.
I think it's possible your email client has mangled the patch, I'm
attaching the same patch to this email, could you try to apply it
again and report back? (this time it should apply cleanly)
Thanks, Roger.
View attachment "v2-0001-xen-blkfront-allow-discard-nodes-to-be-optional.patch" of type "text/plain" (3241 bytes)
Powered by blists - more mailing lists