From: "Darrick J. Wong" <darrick.wong@oracle.com> To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com> Cc: Pavel Reichl <preichl@redhat.com>, "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org> Subject: Re: [PATCH v3] mkfs: Break block discard into chunks of 2 GB Date: Mon, 2 Dec 2019 08:40:38 -0800 Message-ID: <20191202164038.GC7335@magnolia> (raw) In-Reply-To: <BYAPR04MB5749DD0BFA3B6928A87E54B086410@BYAPR04MB5749.namprd04.prod.outlook.com> On Sat, Nov 30, 2019 at 10:01:17PM +0000, Chaitanya Kulkarni wrote: > Not an XFS expert, but patch to handle ^C is been discussed on the > block layer mailing list which includes discard operations. [1] Heh, I wasn't aware of that. :) > This solution seems specific to one file system, which will lead to > code repetition for all the file systems which are in question. > > How about we come up with the generic solution in the block-layer so > it can be reused for all the file systems ? > > (fyi, I'm not aware of any drawbacks of handling ^C it in the block > layer and would like to learn if any). The only one that I can think of is how to signal a partial completion, but if you're only aborting on *fatal* signals then that doesn't matter. Fixing the block layer seems like a better answer anyway. > [1] https://patchwork.kernel.org/patch/11234607/ Though looking through that patch raises the question of whether xfs' control loops also need to check for fatal signals, similar to what the online scrub loops do? --D > -Chaitanya > > On 11/27/2019 10:21 PM, Pavel Reichl wrote: > > Some users are not happy about the BLKDISCARD taking too long and at the same > > time not being informed about that - so they think that the command actually > > hung. > > > > This commit changes code so that progress reporting is possible and also typing > > the ^C will cancel the ongoing BLKDISCARD. > > > > Signed-off-by: Pavel Reichl<preichl@redhat.com> > > --- >
next prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-28 6:21 Pavel Reichl 2019-11-30 22:01 ` Chaitanya Kulkarni 2019-12-02 16:40 ` Darrick J. Wong [this message] 2019-12-04 16:24 ` Eric Sandeen 2019-12-04 17:26 ` Christoph Hellwig 2019-12-04 17:32 ` Eric Sandeen 2019-12-04 17:42 ` Darrick J. Wong 2019-12-10 7:33 ` Chaitanya Kulkarni 2019-12-10 14:20 ` Eric Sandeen 2019-12-09 22:00 ` Eric Sandeen 2019-12-09 23:34 ` Darrick J. Wong 2019-12-10 0:49 ` Eric Sandeen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191202164038.GC7335@magnolia \ --to=darrick.wong@oracle.com \ --cc=Chaitanya.Kulkarni@wdc.com \ --cc=linux-xfs@vger.kernel.org \ --cc=preichl@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-XFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-xfs/0 linux-xfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-xfs linux-xfs/ https://lore.kernel.org/linux-xfs \ linux-xfs@vger.kernel.org public-inbox-index linux-xfs Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-xfs AGPL code for this site: git clone https://public-inbox.org/public-inbox.git