Re: [PATCH 3/3] dm: allow error target to replace immutable target

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 29 Aug 2013, Mike Snitzer wrote:

> On Thu, Aug 29 2013 at  1:07pm -0400,
> Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
> 
> > 
> > 
> > On Thu, 29 Aug 2013, Mike Snitzer wrote:
> > 
> > > On Thu, Aug 29 2013 at 10:37am -0400,
> > > Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
> > > 
> > > > As I said - I think it would be better to remove the immutable flag than 
> > > > to create more flags to bypass it.
> > > 
> > > Immutable was introduced to prevent dangerous scenarios that weren't
> > > accounted for in original design, etc.  It solved your crash when you
> > > rep;aced a thin-pool with an empty table.
> > > 
> > > immutable is staying for now.  And as it turns out allowing error target
> > > to override an immutable target was always held to be a logical/possible
> > > future relaxation of the immutable constraint.
> > > 
> > > Mike
> > 
> > If you can replace a thin-pool target with an error target - so why can't 
> > you replace a thin-pool target with linear (or any other) target?
> > 
> > I don't see why the error target should be special.
> 
> error target gives us the ability to disconnect the thin-pool from the
> underlying devices.  It is practical for testing, etc.
> 
> What use-case are you saying will be valid to switch a thin-pool target
> to linear?

There is no use case. The user can do many stupid useless things with 
dmsetup and it is not the kernel's job to prevent him from doing them.

What I am trying to say is that - adding an immutable flag and then adding 
another flag that bypasses the immutable flag is just pointless 
complication in the code. If you removed the immutable flag and then 
removed the DM_TARGET_ALWAYS_RETURNS_IO_ERROR flag, you end up with 
simpler code.

Mikulas

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux