On Thu, Apr 02, 2020 at 08:45:30PM -0700, Martin K. Petersen wrote: > > 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. Um, so we're supposed to use space allocation before overwriting existing metadata in the filesystem? So that the underlying storage can reserve space for it before we write it? Which would mean we have to issue a space allocation before we dirty the metadata, which means before we dirty any metadata in a transaction. Which means we'll basically have to redesign the filesystems from the ground up, yes? > So far we have mainly been talking about fallocate on block devices. You might be talking about filesystem metadata and block devices, but this patchset ends up connecting ext4's user data fallocate() to the block device, thereby allowing users to reserve space directly in the underlying block device and directly exposing this issue to userspace. I can only go on what is presented to me in patches - this patchset nothing to do with filesystem metadata nor preventing ENOSPC issues with internal filesystem updates. XFS is no different to ext4 or btrfs here - the filesystem doesn't matter because all of them can fallocate() terabytes of space in a second or two these days.... > How XFS decides to enforce space allocation policy and potentially > leverage this plumbing is entirely up to you. Do I understand this correctly? i.e. that it is the filesystem's responsibility to prevent users from preallocating more space than exists in an underlying storage pool that has been intentionally hidden from the filesystem so it can be underprovisioned? IOWs, I'm struggling to understand exactly how the "standards space" think filesystems are supposed to be using this feature whilst also preventing unprivileged exhaustion of a underprovisioned storage pool they know nothing about. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
