[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b89fe35d-cdf9-e652-2016-599d67bdc5eb@toxicpanda.com>
Date: Tue, 1 Sep 2020 13:45:58 -0400
From: Josef Bacik <josef@...icpanda.com>
To: Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>
Cc: Dan Williams <dan.j.williams@...el.com>, dm-devel@...hat.com,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
nbd@...er.debian.org, ceph-devel@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
linux-raid@...r.kernel.org, linux-nvdimm@...ts.01.org,
linux-nvme@...ts.infradead.org, linux-scsi@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: remove revalidate_disk()
On 9/1/20 11:57 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series removes the revalidate_disk() function, which has been a
> really odd duck in the last years. The prime reason why most people
> use it is because it propagates a size change from the gendisk to
> the block_device structure. But it also calls into the rather ill
> defined ->revalidate_disk method which is rather useless for the
> callers. So this adds a new helper to just propagate the size, and
> cleans up all kinds of mess around this area. Follow on patches
> will eventuall kill of ->revalidate_disk entirely, but ther are a lot
> more patches needed for that.
>
I applied and built everything on Jens's for-next, patch #2 was fuzzy but it
applied.
I checked through everything, the only thing that was strange to me is not
calling revalidate_disk_size() in nvdimm, but since it's during attach you point
out it doesn't matter. You can add
Reviewed-by: Josef Bacik <josef@...icpanda.com>
To the series, thanks,
Josef
Powered by blists - more mailing lists