From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wakko Warner Subject: Re: mdadm: Patch to restrict --size when shrinking unless forced Date: Tue, 10 Oct 2017 16:55:57 -0400 Message-ID: <20171010205557.GA11500@animx.eu.org> References: <22997.8664.67459.119616@quad.stoffel.home> <87a81637lq.fsf@notabene.neil.brown.name> <23002.37193.492253.120639@quad.stoffel.home> <87shetz207.fsf@notabene.neil.brown.name> <23002.53075.413063.6948@quad.stoffel.home> <87h8v9yn91.fsf@notabene.neil.brown.name> <20171010000702.GA6038@animx.eu.org> <87y3oiwws3.fsf@notabene.neil.brown.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <87y3oiwws3.fsf@notabene.neil.brown.name> Sender: linux-raid-owner@vger.kernel.org To: NeilBrown Cc: Phil Turmel , John Stoffel , Eli Ben-Shoshan , Jes.Sorensen@gmail.com, linux-raid@vger.kernel.org List-Id: linux-raid.ids NeilBrown wrote: > On Mon, Oct 09 2017, Wakko Warner wrote: > > > Phil Turmel wrote: > >> A certain amount of the trouble with all of this is the english meaning > >> of "grow" doesn't really match what mdadm allows. > >> > >> Might it be reasonable to reject "--grow" operations that reduce the > >> final array size, and introduce the complementary "--reduce" operation > >> that rejects array size increases? > >> > >> Both operations would share the current code, just apply a different > >> sanity check before proceeding. > >> > >> mdadm would then at least not violate the rule of least surprise. > > > > As a general user of md raid and as a reader of the list, I would agree that > > this would be a better solution. Thinking in terms of lvm, there's lvreduce > > and lvextend. IMO, --force wouldn't be needed for --reduce (I was orginally > > thinking of --shrink) > > > > On a side note, is it possible for the lower layers to know what the last > > used sector is? IE lvm ontop of raid and has 10% allocated and the last > > sector is around the 10% mark. (If this were possible --force would be, > > required if shrinking would result in inaccessible data) > > No it isn't. I've occasionally thought of adding functionality so that > the a device could ask its client (e.g. filesystem, lvm, etc) if > shrinking is OK - but it hasn't happened yet. That's what I thought but wasn't sure. Thanks. > > I recently did a shrink of 4x 2tb drives so that I could replace the 2tb > > drives with 80gb drives (yes, big shrink!) Would have been nice for mdadm > > to know the smallest size was that wouldn't destroy my lvm volumes that were > > on top. > > Guess, try, see if data is still accessible. If not, revert the change. > If you have a filesystem on the raid, fsck will complain if you made it > too small. I don't know what you would try with lvm. pvscan? Fortunately for me, my first try worked. -- Microsoft has beaten Volkswagen's world record. Volkswagen only created 22 million bugs.