On Mon, Nov 11 2013 at 4:32pm -0500,
Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
> On Mon, Nov 11 2013 at 4:19pm -0500,
> Alasdair G Kergon <agk@xxxxxxxxxx> wrote:
>
> > On Mon, Nov 11, 2013 at 12:20:43PM -0500, Mike Snitzer wrote:
> > > From: Joe Thornber <ejt@xxxxxxxxxx>
> > >
> > > Allow a cache to shrink if the blocks being removed from the cache are
> > > not dirty.
> >
> > Please would you document the intended procedure here?
>
> I'm not rebasing this patch (and in turn all commits that follow) to
> tweak this header. We can add information to cache.txt as a follow-on
> commit.
>
> > > + DMERR("unable to shrink cache due to dirty blocks");
> >
> > This error is highly undesirable: part of a device has been removed
> > while it is still needed!
>
> Huh? The device still had dirty blocks, so the cache wasn't resized.
Maybe you were saying: the trigger to resize is based on the size of the
fast device having been reduced.. so getting that error _after_ the user
already resized the fast device isn't really useful.
Valid point... but given DM gives users a tremendous amount of room to
hang itself this is par for the course no? Making this more
bullet-proof could have userspace detect that the device is being used
as in a dm-cache device... and then running userspace utils to analyze
whether the device still has dirty blocks.
Kernel is merely acting as it was told.. and yeah the user could do the
wrong thing. So much more documentation is warranted for sure.
Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
