On Wed, Feb 17, 2021 at 08:16:29AM +0100, Christoph Hellwig wrote:
> On Wed, Feb 17, 2021 at 11:07:14AM +0800, Ming Lei wrote:
> > Do you think it is correct for ioctl(BLKRRPART) to always drop/re-add
> > partition device node?
>
> Yes, that is what it is designed to do. The only reason to call
On Wed, Feb 17, 2021 at 11:07:14AM +0800, Ming Lei wrote:
> Do you think it is correct for ioctl(BLKRRPART) to always drop/re-add
> partition device node?
Yes, that is what it is designed to do. The only reason to call this
ioctl is when userspace software has written new partition table
On Tue, Feb 16, 2021 at 09:44:30AM +0100, Christoph Hellwig wrote:
> On Mon, Feb 15, 2021 at 12:03:41PM +0800, Ming Lei wrote:
> > Hello,
>
> I think this is a fundamentally bad idea. We should not keep the
> parsed partition state around forever just to work around some buggy
> user space
On Mon, Feb 15, 2021 at 12:03:41PM +0800, Ming Lei wrote:
> Hello,
I think this is a fundamentally bad idea. We should not keep the
parsed partition state around forever just to work around some buggy
user space software.
On Fri, Feb 05, 2021 at 10:17:06AM +0800, Ming Lei wrote:
> Hi Guys,
>
> The two patches changes block ioctl(BLKRRPART) for avoiding drop &
> re-add partitions if partitions state isn't changed. The current
> behavior confuses userspace because partitions can disappear anytime
> when
Hi Guys,
The two patches changes block ioctl(BLKRRPART) for avoiding drop &
re-add partitions if partitions state isn't changed. The current
behavior confuses userspace because partitions can disappear anytime
when ioctl(BLKRRPART).
Ming Lei (2):
block: move partitions check code into single
6 matches
Mail list logo