How to use trim command ?

[Masachika ISHIZUKA]

Hi.

I'm using FreeBSD 13.0-CURRENT r341327.
I want to use trim command.

# trim /dev/gpt/fbroot-current
trim `/dev/gpt/fbroot-current' offset 0 length 60568829952
dry run: add -f to actually perform the operation
# trim -f /dev/gpt/fbroot-current
trim `/dev/gpt/fbroot-current' offset 0 length 60568829952
trim: `/dev/gpt/fbroot-current': Operation not permitted
carrot# echo $status
66

How can I use /usr/sbin/trim command ?

P.S. My SSDs are as follows.
(1) LITEONIT LMT-256M6M mSATA
% dmesg | grep -i ada0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <LITEONIT LMT-256M6M mSATA 256GB DM8110F> ATA8-ACS SATA 3.x device
ada0: Serial Number TW0XXM305508536E0419
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 244198MB (500118192 512 byte sectors)

(2) Sandisk X600 SATA
% dmesg | grep -i ada0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <SanDisk SD9SB8W512G1122 X6104000> ACS-4 ATA SATA 3.x device
ada0: Serial Number 180678800796
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 488386MB (1000215216 512 byte sectors)
--
Masachika ISHIZUKA

[Eugene Grosbein]

30.11.2018 23:14, Masachika ISHIZUKA wrote:

> I'm using FreeBSD 13.0-CURRENT r341327.
> I want to use trim command.
>
> # trim /dev/gpt/fbroot-current
> trim `/dev/gpt/fbroot-current' offset 0 length 60568829952
> dry run: add -f to actually perform the operation
> # trim -f /dev/gpt/fbroot-current
> trim `/dev/gpt/fbroot-current' offset 0 length 60568829952
> trim: `/dev/gpt/fbroot-current': Operation not permitted
> carrot# echo $status
> 66
>
> How can I use /usr/sbin/trim command ?

It seems this partition is in use (mounted?) and GEOM won't allow to write
to opened partition, you need to close it first (unmount).
Be warned: trim will destroy all data in the partition.

[Ian Lepore]

On Sat, 2018-12-01 at 03:32 +0700, Eugene Grosbein wrote:
> 30.11.2018 23:14, Masachika ISHIZUKA wrote:
>
> >
> >   I'm using FreeBSD 13.0-CURRENT r341327.
> >   I want to use trim command.
> >
> > # trim /dev/gpt/fbroot-current
> > trim `/dev/gpt/fbroot-current' offset 0 length 60568829952
> > dry run: add -f to actually perform the operation
> > # trim -f /dev/gpt/fbroot-current
> > trim `/dev/gpt/fbroot-current' offset 0 length 60568829952
> > trim: `/dev/gpt/fbroot-current': Operation not permitted
> > carrot# echo $status
> > 66
> >
> >   How can I use /usr/sbin/trim command ?
> It seems this partition is in use (mounted?) and GEOM won't allow to
> write
> to opened partition, you need to close it first (unmount).
> Be warned: trim will destroy all data in the partition.

And therein lies yet another reason why trim is such a horrible name
for this tool: nothing about the word trim implies destroying live
useful information. In idiomatic English, the word drips with overtones
of removing only the unneeded excess from something.

Truly, dd (with its 30+ years of association of being THE tool that
operates on disk devices or specified sub-ranges of blocks within them)
is the place for such functionality.

-- Ian

[Eugene Grosbein]

01.12.2018 6:56, Ian Lepore wrote:

> And therein lies yet another reason why trim is such a horrible name
> for this tool: nothing about the word trim implies destroying live
> useful information. In idiomatic English, the word drips with overtones
> of removing only the unneeded excess from something.

That's because it defaults to dry run and its manual pages
emphasizes data imminent destruction several times, in bold.

newfs destroys data too, cat > /dev/da0 does this too,
add the name "dd" itself does not imply data destruction.

Can you invent better name?

> Truly, dd (with its 30+ years of association of being THE tool that
> operates on disk devices or specified sub-ranges of blocks within them)
> is the place for such functionality.

In fact, I like both. Sometimes it's handy to use dd while dealing with
zero blocks inside an image (or /dev/zero) written to single device file.
And sometimes it may be useful to be able to "trim /dev/da0 /dev/ada0" with one call.

[Rebecca Cran via freebsd-hackers]

On Friday, 30 November 2018 17:36:01 MST Eugene Grosbein wrote:
> 01.12.2018 6:56, Ian Lepore wrote:

> newfs destroys data too, cat > /dev/da0 does this too,
> add the name "dd" itself does not imply data destruction.

> Can you invent better name?

'discard'?

--
Rebecca Cran

[Warner Losh]

On Sat, Dec 1, 2018 at 12:50 AM Rebecca Cran via freebsd-hackers <
freebsd-***@freebsd.org> wrote:

> On Friday, 30 November 2018 17:36:01 MST Eugene Grosbein wrote:
> > 01.12.2018 6:56, Ian Lepore wrote:
>
> > newfs destroys data too, cat > /dev/da0 does this too,
> > add the name "dd" itself does not imply data destruction.
>
> > Can you invent better name?
>
> 'discard'?
>

That's a good name. trim has the unfortunate collision with the perl 'trim'
function and similar things that I didn't think of when I recommended it.
It's also nicely technology agnostic.

Warner

[Rick Macklem]

Warner Losh wrote:
>Rebecca Cran wrote:
>> On Friday, 30 November 2018 17:36:01 MST Eugene Grosbein wrote:
>> > 01.12.2018 6:56, Ian Lepore wrote:
>>
>> > newfs destroys data too, cat > /dev/da0 does this too,
>> > add the name "dd" itself does not imply data destruction.
>>
>> > Can you invent better name?
>>
>> 'discard'?
>>
>
>That's a good name. trim has the unfortunate collision with the perl 'trim'
>function and similar things that I didn't think of when I recommended it.
>It's also nicely technology agnostic.

What about something with "ssd" in it, like "ssdbulkerase" or "ssderaseall"?

rick

[Poul-Henning Kamp]

--------
In message <***@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM>, Rick Macklem writes:

>What about something with "ssd" in it, like "ssdbulkerase" or "ssderaseall"?

BIO_DELETE is not limited to SSD, it can also be used to discard encryption
keys for data you no longer want and many other things.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Warner Losh]

On Sat, Dec 1, 2018, 3:14 PM Rick Macklem <***@uoguelph.ca wrote:

> Warner Losh wrote:
> >Rebecca Cran wrote:
> >> On Friday, 30 November 2018 17:36:01 MST Eugene Grosbein wrote:
> >> > 01.12.2018 6:56, Ian Lepore wrote:
> >>
> >> > newfs destroys data too, cat > /dev/da0 does this too,
> >> > add the name "dd" itself does not imply data destruction.
> >>
> >> > Can you invent better name?
> >>
> >> 'discard'?
> >>
> >
> >That's a good name. trim has the unfortunate collision with the perl
> 'trim'
> >function and similar things that I didn't think of when I recommended it.
> >It's also nicely technology agnostic.
>
> What about something with "ssd" in it, like "ssdbulkerase" or
> "ssderaseall"?
>

No. Nothing with ssd in it will get past me. It's not technology specific.

Warner

>

[James Wright]

Borrowing somewhat from PostreSQL, how about something like "vacuum"?



> On 1 Dec 2018, at 20:51, Warner Losh <***@bsdimp.com> wrote:
>
> On Sat, Dec 1, 2018 at 12:50 AM Rebecca Cran via freebsd-hackers <
> freebsd-***@freebsd.org> wrote:
>
>> On Friday, 30 November 2018 17:36:01 MST Eugene Grosbein wrote:
>>> 01.12.2018 6:56, Ian Lepore wrote:
>>
>>> newfs destroys data too, cat > /dev/da0 does this too,
>>> add the name "dd" itself does not imply data destruction.
>>
>>> Can you invent better name?
>>
>> 'discard'?
>>
>
> That's a good name. trim has the unfortunate collision with the perl 'trim'
> function and similar things that I didn't think of when I recommended it.
> It's also nicely technology agnostic.
>
> Warner
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"

[Masachika ISHIZUKA]

>> I'm using FreeBSD 13.0-CURRENT r341327.
>> I want to use trim command.
>
> It seems this partition is in use (mounted?) and GEOM won't allow to write
> to opened partition, you need to close it first (unmount).
> Be warned: trim will destroy all data in the partition.

Thank you for reply.

I misunderstood trim was equivalent to fstrim in linux.
I undotstood that the trim command is the SSD bulk erase tool.
--
Masachika ISHIZUKA

[Allan Jude]

On 2018-11-30 19:31, Masachika ISHIZUKA wrote:
>>> I'm using FreeBSD 13.0-CURRENT r341327.
>>> I want to use trim command.
>>
>> It seems this partition is in use (mounted?) and GEOM won't allow to write
>> to opened partition, you need to close it first (unmount).
>> Be warned: trim will destroy all data in the partition.
>
> Thank you for reply.
>
> I misunderstood trim was equivalent to fstrim in linux.
> I undotstood that the trim command is the SSD bulk erase tool.
>

If you want to enable TRIM on a UFS filesystem, tunefs is the command
you are looking for.

The equivalent to fstrim for UFS is fsck_ffs -E:

Clear unallocated blocks, notifying the underlying device that they are
not used and that their contents may be discarded. This is useful for
filesystems which have been mounted on systems without TRIM support, or
with TRIM support disabled, as well as filesystems which have been
copied from one device to another.

See also the -E and -t flags of newfs(8), and the -t flag of tunefs(8).


--
Allan Jude

[Masachika ISHIZUKA]

>> I misunderstood trim was equivalent to fstrim in linux.
>> I undotstood that the trim command is the SSD bulk erase tool.
>
> If you want to enable TRIM on a UFS filesystem, tunefs is the command
> you are looking for.

Thank you for mail.

I'm using 'tunefs -t enable /dev/ada0pXX', that is equivalent
to 'discard' in fstab on linux.

> The equivalent to fstrim for UFS is fsck_ffs -E:

I think 'fsck_ffs -E' is not suitable for daily midnight cron
job.
--
Masachika ISHIZUKA

[Warner Losh]

On Sat, Dec 1, 2018 at 4:41 AM Masachika ISHIZUKA <***@amail.plala.or.jp>
wrote:

> >> I misunderstood trim was equivalent to fstrim in linux.
> >> I undotstood that the trim command is the SSD bulk erase tool.
> >
> > If you want to enable TRIM on a UFS filesystem, tunefs is the command
> > you are looking for.
>
> Thank you for mail.
>
> I'm using 'tunefs -t enable /dev/ada0pXX', that is equivalent
> to 'discard' in fstab on linux.
>
> > The equivalent to fstrim for UFS is fsck_ffs -E:
>
> I think 'fsck_ffs -E' is not suitable for daily midnight cron
> job.
>

FreeBSD doesn't have an equivalent of a daemon that runs and trims blocks
after a while of being idle (trimd on linux I think).

Warner

[Poul-Henning Kamp]

--------
In message <CANCZdfqsVo_mk4TqJy8pmp+DQvDSg-cgwxM03+xgT5_Y+***@mail.gmail.com>, Warner Losh writes:
>On Sat, Dec 1, 2018 at 4:41 AM Masachika ISHIZUKA <***@amail.plala.or.jp>
>wrote:

>> I think 'fsck_ffs -E' is not suitable for daily midnight cron job.
>
>FreeBSD doesn't have an equivalent of a daemon that runs and trims blocks
>after a while of being idle (trimd on linux I think).

Why would you run 'fsck_ffs -E' in cron anyway ?

If the file-system is has TRIM enabled, it would be a no-op, unless
there are bugs in the fs ?

As for command name: bio_delete(8) would be my suggestion, but I'm biased.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[RW via freebsd-hackers]

On Sat, 01 Dec 2018 21:23:44 +0000
Poul-Henning Kamp wrote:


> Why would you run 'fsck_ffs -E' in cron anyway ?
>
> If the file-system is has TRIM enabled, it would be a no-op, unless
> there are bugs in the fs ?

There's a school of thought that trimming in real-time, after file
deletion, slows down I/O on the device. Some people advocate
turning-off trim support in the file-system and trimming all the
unused space in one go from cron when the system is likely to be idle.

I don't know whether there's any truth in it. It sounds unlikely with
modern drives.

[Poul-Henning Kamp]

--------
In message <***@gumby.homeunix.com>, RW via freebsd-hackers writes:
>On Sat, 01 Dec 2018 21:23:44 +0000

>> Why would you run 'fsck_ffs -E' in cron anyway ?
>>
>> If the file-system is has TRIM enabled, it would be a no-op, unless
>> there are bugs in the fs ?
>
>There's a school of thought that trimming in real-time, after file
>deletion, slows down I/O on the device.

I suspect people would have reached that conclusion back when various
shady outfits started selling camera-grade FAL devices in 2.5"
form-factor.

My advice would be to avoid any device where that pattern is observed,
because that means there is too few write buffers and paths.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Warner Losh]

On Sat, Dec 1, 2018, 3:43 PM Poul-Henning Kamp <***@phk.freebsd.dk wrote:

> --------
> In message <***@gumby.homeunix.com>, RW via
> freebsd-hackers writes:
> >On Sat, 01 Dec 2018 21:23:44 +0000
>
> >> Why would you run 'fsck_ffs -E' in cron anyway ?
> >>
> >> If the file-system is has TRIM enabled, it would be a no-op, unless
> >> there are bugs in the fs ?
> >
> >There's a school of thought that trimming in real-time, after file
> >deletion, slows down I/O on the device.
>
> I suspect people would have reached that conclusion back when various
> shady outfits started selling camera-grade FAL devices in 2.5"
> form-factor.
>
> My advice would be to avoid any device where that pattern is observed,
> because that means there is too few write buffers and paths.
>

Erase has become super expensive with QLC nand. And many SSDs are trying to
use simpler, smaller data structures to implement its LUTs. This makes
trims too expensive. There are also others that can do some trims w/o any
hassles, but if you trim 5s or 10s of gig at a time, it causes issues. Then
metering the trims out helps a lot... but it is very workload specific...

Warner

--
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> ***@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"
>

[Poul-Henning Kamp]

--------
In message <CANCZdfrb0gWAhSUAVvs0pBjezWgh3c_kHjriknC02KZF+***@mail.gmail.com>, Warner Losh writes:

>Erase has become super expensive with QLC nand. And many SSDs are trying to
>use simpler, smaller data structures to implement its LUTs.

They may not have a choice, there are patent-issues in this space.

Still, I would avoid any SSD which has issues in this space for normal
filesystem operations.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Warner Losh]

On Sun, Dec 2, 2018 at 12:03 AM Poul-Henning Kamp <***@phk.freebsd.dk>
wrote:

> --------
> In message <
> CANCZdfrb0gWAhSUAVvs0pBjezWgh3c_kHjriknC02KZF+***@mail.gmail.com>,
> Warner Losh writes:
>
> >Erase has become super expensive with QLC nand. And many SSDs are trying
> to
> >use simpler, smaller data structures to implement its LUTs.
>
> They may not have a choice, there are patent-issues in this space.
>
> Still, I would avoid any SSD which has issues in this space for normal
> filesystem operations.
>

Good advice, if you can afford the more expensive NAND... Cost reduction
efforts have lead me to try to make such NAND suck less.

Warner

[Warner Losh]

On Sat, Dec 1, 2018, 3:27 PM RW via freebsd-hackers <
freebsd-***@freebsd.org wrote:

> On Sat, 01 Dec 2018 21:23:44 +0000
> Poul-Henning Kamp wrote:
>
>
> > Why would you run 'fsck_ffs -E' in cron anyway ?
> >
> > If the file-system is has TRIM enabled, it would be a no-op, unless
> > there are bugs in the fs ?
>
> There's a school of thought that trimming in real-time, after file
> deletion, slows down I/O on the device. Some people advocate
> turning-off trim support in the file-system and trimming all the
> unused space in one go from cron when the system is likely to be idle.
>

That's an interesting idea. One that would be hard to do on FreeBSD.


I don't know whether there's any truth in it. It sounds unlikely with
> modern drives.
>

I'm working on a better way to meter the TRIMs to the drive fast enough to
make progress, but slow enough to not affect other operations. I think the
locking will be simpler than trimd, and the feedback loop will keep trims
in budget.

There are still drives out there which need it. The low end is still...
under resourced...

Warner

_______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"
>

[Rodney W. Grimes]

> On Sat, Dec 1, 2018 at 12:50 AM Rebecca Cran via freebsd-hackers <
> freebsd-***@freebsd.org> wrote:
>
> > On Friday, 30 November 2018 17:36:01 MST Eugene Grosbein wrote:
> > > 01.12.2018 6:56, Ian Lepore wrote:
> >
> > > newfs destroys data too, cat > /dev/da0 does this too,
> > > add the name "dd" itself does not imply data destruction.
> >
> > > Can you invent better name?
> >
> > 'discard'?
> >
>
> That's a good name. trim has the unfortunate collision with the perl 'trim'
> function and similar things that I didn't think of when I recommended it.
> It's also nicely technology agnostic.

That word is also used in other parts of FreeBSD in
similiar situations:
strip(1) - discard information from ELF objects
disc, if_disc(4) - software discard network interface
edsc, if_edsc(4) - Ethernet discard network interface
ng_hole(4) - netgraph discard node type

I was kinda suprized to see strip come up....

--
Rod Grimes ***@freebsd.org