1 |
On 04/26 11:20, Rich Freeman wrote: |
2 |
> On Sun, Apr 26, 2020 at 10:52 AM <tuxic@××××××.de> wrote: |
3 |
> > |
4 |
> > Fstrim reports about 200 GiB of trimmed data. |
5 |
> > |
6 |
> > From the gut this looks quite a lot -- the whole |
7 |
> > partition is 256 GB in size. |
8 |
> > |
9 |
> > Smartclt report for the drive: |
10 |
> > Data Units Written: 700,841 [358 GB] |
11 |
> > |
12 |
> > Each week 200 GiB fstrimmed data for a partition of |
13 |
> > 256 GB in size and since the beginning I have written |
14 |
> > only 358 GB to it. |
15 |
> > |
16 |
> > How does this all fit together? |
17 |
> |
18 |
> It doesn't fit together, because the amount of space trimmed has |
19 |
> nothing to do with the amount of data written. |
20 |
> |
21 |
> How much free space is there? I would think that fstrim would just |
22 |
> trim all unused blocks on the filesystem. Unless it maintained state |
23 |
> it would have no idea what has changed since the last time it was run, |
24 |
> so if you ran it 10 times in a row it would trim 200GiB each time. |
25 |
> |
26 |
> Unless your NVMe is brain-dead the only real downside to running it |
27 |
> more often is the IO. If you trim 200GiB of data 100x in a row the |
28 |
> 99x after the first one should all be no-ops if the drive is |
29 |
> well-designed. An fstrim should just be a metadata operation. |
30 |
> |
31 |
> Now, not all flash storage is equally well-implemented, and I suspect |
32 |
> the guidelines to avoid running it often or using discard settings are |
33 |
> from those who either have really cheap drives, or ones from a long |
34 |
> time ago. A lot of linux advice tends to be based on what people did |
35 |
> 10+years ago, and a lot of linux design decisions get made to |
36 |
> accommodate the guy who wants everything to work fine on his 386+ISA |
37 |
> and SGI Indigo in his basement. |
38 |
> |
39 |
> My suggestion would be to run fstrim twice in a row and see how fast |
40 |
> it operates and what the results are. If the second one completes |
41 |
> very quickly that suggests that the drive is sane. I'd probably just |
42 |
> run it daily in that case, but weekly is probably fine especially if |
43 |
> the drive isn't very full. |
44 |
> |
45 |
> -- |
46 |
> Rich |
47 |
> |
48 |
|
49 |
Hi Rich, |
50 |
|
51 |
thanks for explanation. |
52 |
|
53 |
My observations does not fit with your explanation, though. |
54 |
|
55 |
Early in the morning I did a fstrim, which results in the |
56 |
200GiB of freed data. |
57 |
|
58 |
Base on you posting I did a fstrim now with no |
59 |
wait in between: |
60 |
|
61 |
host:/root>fstrim -v / |
62 |
/: 3.3 GiB (3578650624 bytes) trimmed |
63 |
host:/root>fstrim -v / |
64 |
/: 0 B (0 bytes) trimmed |
65 |
|
66 |
This time the first fstrim reports a small mount of trimmed |
67 |
data and second one no fstrimmed data at all. |
68 |
|
69 |
The SSD is a |
70 |
ADATA Technology Co., Ltd. XPG SX8200 Pro PCIe Gen3x4 M.2 2280 Solid State Drive (rev 03) |
71 |
(cut'n'paste from `lspci`) |
72 |
|
73 |
host:/root>df -h / |
74 |
Filesystem Size Used Avail Use% Mounted on |
75 |
/dev/root 246G 45G 189G 20% / |
76 |
|
77 |
|
78 |
Cheers! |
79 |
Meino |