[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1a73t44h1.fsf@oracle.com>
Date: Thu, 2 Apr 2020 20:45:30 -0700 (PDT)
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Dave Chinner <david@...morbit.com>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Chaitanya Kulkarni <chaitanya.kulkarni@....com>, hch@....de,
darrick.wong@...cle.com, axboe@...nel.dk, tytso@....edu,
adilger.kernel@...ger.ca, ming.lei@...hat.com, jthumshirn@...e.de,
minwoo.im.dev@...il.com, damien.lemoal@....com,
andrea.parri@...rulasolutions.com, hare@...e.com, tj@...nel.org,
hannes@...xchg.org, khlebnikov@...dex-team.ru, ajay.joshi@....com,
bvanassche@....org, arnd@...db.de, houtao1@...wei.com,
asml.silence@...il.com, linux-block@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/4] block: Add support for REQ_OP_ASSIGN_RANGE
Dave,
> .... because when backed by thinp storage, plumbing user level
> fallocate() straight through from the filesystem introduces a
> trivial, user level storage DOS vector....
>
> i.e. a user can just fallocate a bunch of files and, because the
> filesystem can do that instantly, can also run the back end array
> out of space almost instantly. Storage admins are going to love
> this!
In the standards space, the allocation concept was mainly aimed at
protecting filesystem internals against out-of-space conditions on
devices that dedup identical blocks and where simply zeroing the blocks
therefore is ineffective.
So far we have mainly been talking about fallocate on block devices. How
XFS decides to enforce space allocation policy and potentially leverage
this plumbing is entirely up to you.
--
Martin K. Petersen Oracle Linux Engineering
Powered by blists - more mailing lists