In my current setup, I have three different filesystems on two different SSDs: A FAT partition and a BTRFS partition on one drive, and ext4 on a second drive. When running fstrim, [the output is apparently](https://www.reddit.com/r/linuxquestions/comments/vaahg7/comment/ic1es8n/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) [not very usable](https://superuser.com/a/1251947/277646) and basically each of those filesystems reports some meaningless value for the amount that got trimmed. Since truly [free space on an SSD contributes to its performance](https://cdn.mos.cms.futurecdn.net/3XW98AqWgfM956j5FGcodL.png) , at least for QLC NAND modules that use an SLC cache, I wanted to see if I could determine the impact of running fstrim. I know that utilities like df and duf, as well as lsblk provide usage information based on the filesystem, but are there any utilities that can show the drive sectors that are in use vs free? If my understanding of how TRIM on an SSD works is correct, then the filesystem will show reduced space immediately upon deleting a file, but those sectors are still considered in use by the SSD controller. After TRIM, those sectors would be freed. I'm hoping for a way to see the extent of that

It looks like my OS is set to periodically trim portable SSD drives, and TRIM is supported by my portable SSD. I connect this SSD via its usbc cable, attached to the usbc to usb3 adapter that came in the box with it, then connected to the usb2 port on my laptop. Is trim actually executed? I read that trim commands are not supported through usb 2.0... for example here is written that usb2 does not support trim: https://wiki.gentoo.org/wiki/Discard_over_USB (section prerequisites). Also https://en.m.wikipedia.org/wiki/USB_Attached_SCSI says that it depends on the hardware and sometimes usb hub... Does it mean that I have to investigate specifically my motherboard?

After reading online I was under the impression that TRIM is not *automatically* (periodically) sent over to my USBconnected SSD by Fedora; but some discussions on this forum make me doubt this. Anyone has clarifications? Thank you so much.

I have an HDD used for archival purposes. I had to format it with NTFS to keep it accessible from Windows. I need TRIM support (because the HDD is SMR...) and NTFS can't trim without the discard option for some reason. Can I automatically add the discard option whenever an ntfs partition is mounted?

On Linux, this command fstrim -av I will remove all unused blocks (particularly interesting on VM disks and necessary on SSD to preserve/get a longer duration). NetBSD has a similar command called blkdiscard This command wipes the entire disk, so it becomes unusable (correct me if I am wrong) blkdiscard -v /dev/rwd... I see there is a flag which starts to discard after some bytes (or MB) blkdiscard -v -f 256m -m 128m /dev/rwd0c Suppose my partition uses 6GB of data, to make a safe discard (my data still remains), is this the correct command? blkdiscard -v -f 6000m -m 128m /dev/rwd0c

Is possible to resize a qemu/libvirt image maintaining virtual size and at same time don't loss data? I explain better: when you create a virtual disk qemu-img create -f qcow2 debian-GEN.qcow2 60G The virtual machine see a disk of 60G, but the space used is the space which the vm has used (this example is after installing some software) qemu-img info debian-GEN.qcow2 image: debian-GEN.qcow2 file format: qcow2 virtual size: 60 GiB (64424509440 bytes) disk size: 3.1 GiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false refcount bits: 16 corrupt: false extended l2: false Child node '/file': filename: debian-GEN.qcow2 protocol type: file file length: 4.61 GiB (4948164608 bytes) disk size: 3.1 GiB Now the problem. Suppose I wrote 20GB of additional data, the disk size became 23GB (3.1+20), suppose then I remove 20GB of data (with rm -fr or even shred), the disk size is still 23GB! My question is this: there is a way to remove the 20GB of unused data from the virtual disk? So the image return 3.1GB (but the vm still see the 60GB space)?

I want to clopy a partition between SSD devices. Normally I could do it simply with the "dd" or "buffer" commands. However, now that I have SSDs, I also would like to miss the unneeded writes. *I want all all-zero blocks handled as trimmed blocks.* Is there, ideally a command line tool, to do that?

I have an FFmpeg command to trim audio: ffmpeg -ss 01:43:46 -t 00:00:44.30 -i input.mp3 output.mp3 The problem I have with this command is that option -t requires a duration (in seconds) from *01:43:46*. I want to trim audio using start/stop times, e.g. between *01:43:46* and *00:01:45.02*. Is this possible?

I don't want to display the first directory component of paths printed by the inner find command from the below example

find . ! -name . -prune -type d -exec sh -c '
for dir do
echo "\n\n${dir#.*/}\n"
find "$dir" -exec md5sum {\} +
done' sh {} + >> ../md5

Output example:

dir1

md5sum value ./dir1/file1

dir2

md5sum value ./dir2/dir3/file2

I do not want to display the first directory component i.e ./dir1 and ./dir2 in the ./dir1/file1, ./dir2/dir3/file2 paths, instead I want find to print ./file1 and ./dir3/file2 Is there any way to do that? Thank you in advance

I would put my Ubuntu 22.04 NVME disk into this USB 3.2 20Gbps M.2 NVMe SSD Enclosure and boot it from a USB 3.2x2 port. I know that a SSD needs to be trimmed by FSTRIM, but I also read that accomplish this, through an external USB enclosure, should be a trivial task. In this old post the above topic has been already discussed, and somebody suggested to rely on the UDEV rules, as explained here . My questions are: 1. Could the above UDEV approach work? 2. Could the UDEV rule work for a USB boot SSD too? 3. A friend of mine boots his Ubuntu OS by a UGREEN enclosure, regardless of the TRIM. What could happen to the SSD if we don't care of the trimming? 4. If trimming over USB will not be allowed (is it harmful?), why SSD enclosures exist on the market? Thank you in advance!

It used to be that properly enabling TRIM for SSDs on Linux involved two steps: 1. Running fstrim once, to take care of all the "untrimmed" blocks to date, then 2. Setting the discard flag in *fstab* (so the trimming would continue). I'm a little behind the times. Now I'm seeing things about an [*fstrim.timer* service](https://forums.linuxmint.com/viewtopic.php?t=292795) that is included in newer Linux distributions, and I'm seeing conflicting information about which combination of *fstrim.timer*, fstrim, and discard to use. My question is, on modern Linuxes (modern at the time of this writing), what's the preferred way to enable TRIM on an SSD? Is it just to enable *fstrim.timer* and let it do its thing? Is the usage of the discard flag no longer necessary? If it matters I'm specifically interested in Ubuntu >= 22 (Jammy) and Debian >= 10 (Buster).

I have a drive (SD card) with a few ext4 partitions but also some unallocated space. The fstrim utility can only work within a filesystem. Before I reinvent the wheel and write one, is there another utility that can TRIM the unallocated space (or that can TRIM an explicitly specified range)? I can verify that the majority of the unallocated space on the device is *not* currently known to be free by the controller, as I've observed that, on this particular card, reads to trimmed space return 0's, but a scan of the device shows plenty of garbage data left over. Edit: I am having an issue using hdparm. The example below discards the first sector, but I am seeing the same results regardless of the range I specify. fstrim has no issues on the device: root@ubuntu:~# hdparm --please-destroy-my-drive --trim-sector-ranges 0:1 --verbose /dev/mmcblk0 /dev/mmcblk0: trimming 1 sectors from 1 ranges outgoing cdb: 85 0d 06 00 01 00 01 00 00 00 00 00 00 40 06 00 outgoing_data: 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ioctl(fd,SG_IO): Invalid argument FAILED: Invalid argument I am investigating further but does anybody have any insight?

I have an old mSATA SSD (model name: Plextor PX-128M6M), which is installed to an mSATA-to-USB enclosure with ASM1153E controller. I want to *(just logically, at the SSD controller level)* erase all of its data. However, it seemed that: 1. blkdiscard command does not actually erase all requested region of data, just the beginning 2GiB minus 32KiB of data was actually erased. 2. hdparm --trim-sector-ranges-stdin seems to work fine, however, the SSD controller *(of this model of SSD specifically, another model does not seem to behave like this)* seems to be protecting the first 8 sectors (4KiB of data) from being erased by TRIM command. -------- My attempts and experiments are as follows: 1. I was doing this under Ubuntu 23.04. 2. Thanks to the guides from Arch Wiki, I found that I have to set /sys/block/sdX/device/scsi_disk/*/provisioning_mode to unmap first. It was full initially. After that, I thought the system was then able to send SCSI UNMAP command (through UASP, translated into TRIM command by the controller) to the old SSD. 3. I then did this to the whole drive: blkdiscard -f -v /dev/sdX (sdX is the actual device name), it then reported that all bytes (matches with the disk capacity) was discarded (erased), however I found that both the main GPT and the backup GPT at the beginning/end of disk space were still not erased. 4. I created a partition sized 2GiB, and then filled it with random data drained from /dev/urandom. 5. blkdiscard -f -v /dev/sdX was done on the whole drive, hexdump then showed that the last 1MiB + 32KiB of the first partiton was not erased (the partition starts from LBA 2048, with a sector size of 512 Bytes). 6. After re-executing blkdiscard -f -v /dev/sdX1 on the new partition instead of the whole drive, hexdump showed that the last 32KiB of this partition was not erased. 7. I then tried hdparm --trim-sector-ranges-stdin, with a list of all sectors of the whole drive fed from stdin. This time the main GPT still stood, but all remaining data was erased to zero. 8. I filled the first 2048 sectors with /dev/urandom data. Then hdparm --trim-sector-ranges-stdin seemed to erase all data except the first 8 sectors (4KiB of data). -------- To confirm that the behavoir of first 8 sectors not being erased is enforced by the SSD controller instead of mSATA-to-USB chip: 9. I then installed this old Plextor SSD as an internal mSATA drive without USB enclosure. The first 8 sectors still survived after hdparm --trim-sector-ranges-stdin. 10. I have another newer Kingston-branded mSATA SSD. I tested it with hdparm --trim-sector-ranges-stdin, but all sectors went zero without one single exception, no matter it's USB-enclosed or directly installed as an internal drive.

Currently working on a command in AppleScript to trim weight data we receive from a scale. We receive the weight in the following format X.XXX. lb. The Xs representing numbers. We're trimming out 6 spaces before the digits as well as 3 spaces,lb, and 5 more spaces. Using the following command we've managed to trim characters and get the weight to read as X.XXX.. in our files metadata: ~~~ | sed 's/[.^0-9]//g' ~~~ We're hoping to also trim off the two decimal points following the thousandth character in the weight data. Unsure of where to go. EDIT: To help make it more clear what exactly is happening we are using a program to write image files on MacOS. The section of script I'm working on is to trim this weight data before exiftool writes metadata for our image files. In my examples of the different states of the text above the Xs are all numbers that can always vary however the scale doesn't read past the thousandth decimal point. So after the first Decimal we will never get more than 3 numerical digits before the first decimal we may have up to 2 numerical digits in this case we would receive XX.XXX and would need to trim excess characters while not losing the numbers. hopefully this helps better understand the problem if we weigh a package the scale sends the data to our program in the following: ~~~ 1.392. lbs. ~~~ we've managed to get our script to trim this to 1.392.. before writing metadata for the files. hoping to remove those last two decimals as well, while also making sure in the case of a weight reading being double digits i.e. 11.987 we can still perform the same trim. I'm using a program to capture image files and using AppleScript to write .jpgs from the raw camera files. This is executed when a button is clicked in our program. im receiving weight data from a scale in the following format: the following section of our script is trimming that down: ~~~ set thePath to "Macintosh HD:Users:Shared:CS:" if thePath is equal to thePath then -- Format the weight value to remove extra spaces and decimals set cleanWeightValue to do shell script "echo " & weightValue & " | sed 's/[^0-9.]//g'" -- Update Exif metadata with cleanWeightValue do shell script "/usr/local/bin/exiftool '-Description=je " & cleanWeightValue & " lbs' " & quoted form of POSIX path of thePath & "front.JPG" do shell script "/usr/local/bin/exiftool '-Caption-Abstract=je " & cleanWeightValue & " lbs' " & quoted form of POSIX path of thePath & "front.JPG" do shell script "/usr/local/bin/exiftool '-ImageDescription=je " & cleanWeightValue & " lbs' " & quoted form of POSIX path of thePath & "front.JPG" end if ~~~ following this our weight reads in the following format in each image's metadata: our goal is to also trim out those last two decimal points. wondering if this is possible building off our existing sed command

fstrim requires the Linux block device to be mounted, and it is not very verbose. blkdiscard could tell, but also that would require a write operation. Can I somehow tell if a block device supports trimming/discarding, without actually trying to trim/discard something on it?

First apologies if this has been asked before, but I could not find any link with any combination of keywords. My question is - How do SSD optimisations work in BTRFS in a RAID1 where both devices are SSDs? Also fstrim does not seem to pick up /dev/sdb1. See output at the end of this post. I have /dev/sda1 and /dev/sdb1 (both partitions on SSDs) in a RAID1 configuration. But I see no message for sdb1 in the following dmesg output.

pi@testpi:~ $ dmesg | grep btrfs
[Thu Apr 20 00:35:06 2023] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no
[Thu Apr 20 00:35:06 2023] BTRFS: device label nasdisk_01 devid 1 transid 200 /dev/sdd1 scanned by systemd-udevd (209)
[Thu Apr 20 00:35:06 2023] BTRFS: device fsid 69f422a2-fea7-424c-886b-f291068dae9f devid 4 transid 73286 /dev/sdb1 scanned by systemd-udevd (205)
[Thu Apr 20 00:35:06 2023] BTRFS: device fsid 69f422a2-fea7-424c-886b-f291068dae9f devid 3 transid 73286 /dev/sda1 scanned by systemd-udevd (204)
[Thu Apr 20 00:35:06 2023] BTRFS info (device sdd1): using crc32c (crc32c-generic) checksum algorithm
[Thu Apr 20 00:35:06 2023] BTRFS info (device sdd1): setting nodatacow, compression disabled
[Thu Apr 20 00:35:06 2023] BTRFS info (device sdd1): disk space caching is enabled
[Thu Apr 20 00:35:06 2023] BTRFS info (device sda1): using crc32c (crc32c-generic) checksum algorithm
[Thu Apr 20 00:35:06 2023] BTRFS info (device sda1): disk space caching is enabled
[Thu Apr 20 00:35:07 2023] BTRFS info (device sdd1): enabling ssd optimizations
[Thu Apr 20 00:35:07 2023] BTRFS info (device sda1): enabling ssd optimizations

My fstab (partial - non-btrfs entries are removed here) is

PARTUUID=9c860f91-01  /mnt/raid1_01 btrfs    defaults,noatime,nodiratime  0       2
PARTUUID=9c860f91-01  /mnt/media    btrfs    defaults,noatime,nodiratime,subvol=@media  0       2
PARTUUID=9c860f91-01  /mnt/docker-containers    btrfs    defaults,noatime,nodiratime,subvol=@docker-containers  0       2
PARTUUID=9c860f91-01  /mnt/shared-samba    btrfs    defaults,noatime,nodiratime,subvol=@shared-samba  0       2
PARTUUID=9c860f91-01  /mnt/shared-onedrive    btrfs    defaults,noatime,nodiratime,subvol=@shared-onedrive  0       2
PARTUUID=9c860f91-01  /mnt/docker-containers-databases  btrfs    defaults,noatime,nodiratime,subvol=@docker-containers-databases  0       2
PARTUUID=9c860f91-01  /mnt/work     btrfs    defaults,noatime,nodiratime,subvol=@work  0       2

Output of mount command is as following

pi@testpi:~ $ mount | grep btrfs
/dev/sdd1 on /mnt/nasdisk_01 type btrfs (rw,noatime,nodiratime,nodatasum,nodatacow,ssd,space_cache,subvolid=5,subvol=/)
/dev/sda1 on /mnt/docker-containers-databases type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=394,subvol=/@docker-containers-databases)
/dev/sda1 on /mnt/shared-samba type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=363,subvol=/@shared-samba)
/dev/sda1 on /mnt/shared-onedrive type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=391,subvol=/@shared-onedrive)
/dev/sda1 on /mnt/work type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=397,subvol=/@work)
/dev/sda1 on /mnt/docker-containers type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=362,subvol=/@docker-containers)
/dev/sda1 on /mnt/media type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=398,subvol=/@media)
/dev/sda1 on /mnt/raid1_01 type btrfs (rw,noatime,nodiratime,ssd,space_cache,subvolid=5,subvol=/)

Output of fstrim which shows that /dev/sdb1 is ignored.

pi@testpi:~ $ sudo fstrim -vA
/mnt/nasdisk_01: 2.2 GiB (2363473920 bytes) trimmed on /dev/sdd1
/mnt/raid1_01: 5 GiB (5337776128 bytes) trimmed on /dev/sda1
/: 2.9 GiB (3139751936 bytes) trimmed on /dev/sdc2
/boot: 201.8 MiB (211645952 bytes) trimmed on /dev/sdc1

I have the following partition table:

NAME            
nvme0n1         
├─nvme0n1p1           part  /boot
└─nvme0n1p2           part
  └─crypt             crypt
    ├─crypt-swap      lvm   [SWAP]
    ├─crypt-root      lvm   /
    └─crypt-home      lvm   /home

As the drive is an SSD, I would like to perform [TRIM](https://en.wikipedia.org/wiki/Trim_(computing)) command in order to increase performance/lifetime of the disk itself. In particular, I would like to enable periodic TRIM. Because the second partition (i.e., nvme0n1p2) is encrypted, TRIM will be inhibited because of security implications (https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)) . However, it is possible to enable TRIM on encrypted partition by configuring encrypt on the opening. As I my partition is opened at kernel boot, I've modified kernel parameters (i.e., allow-discards):

cryptdevice=/dev/sdaX:root:allow-discards

(*Note that the partition naming and volume name are not relevant in the above snippet.*). By doing that, I was indeed successfully able to run TRIM command on the disk:

# cryptsetup luksDump /dev/nvme0n1p2 | grep Flags
Flags:   allow-discards

And:

# fstrim ...
/home: [..] trimmed on ...
/: [..] trimmed on

So far, so good. --- The problem arose when I tried to restore to the original state. I have removed the kernel parameter allow-discards, but Flags on partition still shows allow-discards and fstrim command successfully complete its job. * How is that possible? * How to restore denying of discards on the encrypted partition?

I know that btrfs support trim/discard, as a mount option or manually (fstrim -A). I want to made a raid1 of ssd, I will get any problem with trim?

I have a running Linux 4.19 amd64 system with two PCIe SSDs that I'd like to clear, test, reformat and put in use again. All of the data has already been moved away. I've - tried to trim/discard blocks from the SSD devices /dev/sdX with hdparm, but it said that the devices "do not support SSD TRIM". - tested the random R/W speed with different block sizes - successfully - created md RAID 10 (far 2) /dev/md/ssd taking care of chunk sizes / alignment - just to test, created an ext4 FS over the RAID and it showed that it was discarding the device blocks, which did take some time (as I would expect). - Encouraged by that I've unmounted the FS and then issued blkdiscard -v /dev/md/ssd but it did not produce any output and is blocked (state D) since more than 12 hours. Reading from /dev/md/ssd is still possible, writing few blocks to the start was/is possible, but following writes are blocked (D+) since hours. Killing blkdiscard, with TERM or KILL does apparently nothing. Stopping the RAID is not possible, mdadm reports that it is busy - in use by the blkdiscard process. Are there any options to resolve that short of rebooting the system? (Rebooting is costly because I'd drive to the site, just in case...)

I recently had to buy a new hard disk for my system. I'm running on a ssd, but for virtual machines i tend to use a hard disk. Since it had to be partitioned and formatted, i used LVM to add it to its own volume group and created one logical volume which was formatted with ext4. Everything works fine. But when i trimmed my ssd with fstrim it took way too long. Turns out, that my hard disk was trimmed, too! The filesystem is created with: Default mount options: journal_data_ordered user_xattr acl Mount options: barrier nodiscard utf8 I confirmed this later with the tool blktrace which reports trimming calls to this logical volume. Somewhere between the lines i even saw a DEL or DL with some nummeric address. My question is: Does enable LVM2 hard disks to be trimmed? Could it be, that the hard disk supports this? (IIRC it would have to, so that fstrim can work on it) I'm old enough to know PIO. The first optimization was to eradicate the zeroing. I'd like to trim my hard disks, so that everything gets zeroed. I could disable trim when mounting and issue it with fstrimwhen the time fits. Would be great, if it all works out as described.