public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Levy <contact@ericlevy.name>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: trim calls not occurring during device removal operation
Date: Thu, 10 Nov 2022 05:10:43 -0500	[thread overview]
Message-ID: <VXM4LR.EC4IKXTTFU8W1@ericlevy.name> (raw)

I recently removed a device from a filesystem. All the devices in the 
file system were thin-provisioned LUNs. From the LUN manager, I was 
able to monitor the space allocated for each LUN. I noticed that during 
the operation, as the file system consumed increasing amounts of space 
from the other devices (from transferring the data off the one being 
removed), none of the deallocated space was freed on the backend for 
the device targeted for removal. Apparently, the file system was not 
calling a hardware trim operation for freed space.

For physical devices, such behavior might not be problematic. However, 
for logical devices backed on storage with usage approaching capacity, 
it is preferred to free space as soon as possible. If a single 
operation consumes increasing space on the backend but frees none, then 
the space on the backed may become depleted before the operation 
completes.

The file system had been mounted with the `discard` option set to 
`async`. In addition to noticing that the option was not causing trim 
calls to be made during the remove operation, I also noticed that calls 
to the `fstrim` system utility targeting the mounted file system did 
not cause any of the space to be trimmed.

In order to avoid overconsumption of space on the backend, it would be 
helpful to trim space as it is freed on a device targeted for an 
ongoing removal operation. Even if the backend space is not imediately 
needed, freeing the space as part of the removal operation would leave 
the device in a state that clearly signals to the LUN adminstrator that 
the LUN is no longer storing data, and so may be safely destroyed. It 
reduces the chance of data loss by human error if an administrator may 
understand that a LUN may be safely destroyed if and only if it is not 
showing as having allocated space.

Would you consider adding more robust support for trim operations as 
part of device removal?

All of my observations occurred under kernel 5.15.



                 reply	other threads:[~2022-11-10 10:10 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=VXM4LR.EC4IKXTTFU8W1@ericlevy.name \
    --to=contact@ericlevy.name \
    --cc=linux-btrfs@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox