1 |
On 04/28 03:12, Kent Fredric wrote: |
2 |
> On Sun, 26 Apr 2020 18:15:51 +0200 |
3 |
> tuxic@××××××.de wrote: |
4 |
> |
5 |
> > Filesystem Size Used Avail Use% Mounted on |
6 |
> > /dev/root 246G 45G 189G 20% / |
7 |
> |
8 |
> Given that (Size - Used) is roughly 200G, it suggests to me that |
9 |
> perhaps, some process somewhere is creating and deleting a lot of |
10 |
> temporary files on this device (or maybe simply re-writing the same |
11 |
> file multiple times) |
12 |
> |
13 |
> From a userspace, this would be invisible, as the "new" file would be |
14 |
> in a new location on the disk, and the "old" file would be invisible, |
15 |
> and marked "can be overwritten". |
16 |
> |
17 |
> So if you did: |
18 |
> |
19 |
> for i in {0..200}; do |
20 |
> cp a b |
21 |
> rm a |
22 |
> mv b a |
23 |
> done |
24 |
> |
25 |
> Where "a" is a 1G file, I'd expect this to have a *ceiling* of 200G |
26 |
> that would turn up in fstrim output, as once you reached iteration 201, |
27 |
> where "can overwrite" would allow the SSD to go back and rewrite over |
28 |
> the space used in iteration 1. |
29 |
> |
30 |
> While the whole time, the visible disk usage in df -h would never |
31 |
> exceed 46G . |
32 |
> |
33 |
> I don't know if this is what is happening, I don't have an SSD and |
34 |
> don't get to use fstrim. |
35 |
> |
36 |
> But based on what you've said, the results aren't *too* surprising. |
37 |
> |
38 |
> Though its possible the hardware has some internal magic to elide some |
39 |
> writes, potentially making the "cp" action incur very few writes, which |
40 |
> would show up in the smartctl data, but ext4 might not know anything |
41 |
> about that, so perhaps fstrim only indicates what ext4 *tracked* as |
42 |
> being cleaned, while it may have incurred much less cleanup required on |
43 |
> the hardware. |
44 |
> |
45 |
> That would explain the difference between smartctl and fstrim results. |
46 |
> |
47 |
> Maybe compare smartctl output over time with |
48 |
> /sys/fs/ext4/<device>/session_write_kbytes and see if one grows faster |
49 |
> than the other? :) |
50 |
> |
51 |
> My local session_write_kbytes is currently at 709G, the partition its |
52 |
> for is only 552G, with 49G space, and its been booted 33 days, so "21G |
53 |
> of writes a day". |
54 |
> |
55 |
> And uh, lifetime_write_kbytes is about 18TB. Yikes. |
56 |
> |
57 |
> ( compiling things involves a *LOT* of ephemeral data ) |
58 |
> |
59 |
> Also, probably don't assume the amount of free space on your partition |
60 |
> is all the physical device has at its disposal to use. It seems |
61 |
> possible that on the hardware, the total pool of "free blocks" is |
62 |
> arbitrarily usable by the device for wear levelling, and a TRIM command |
63 |
> to that device could plausibly report more blocks trimmed than your |
64 |
> current partition size, depending on how its implemented. |
65 |
> |
66 |
> But indeed, lots of speculation here on my part :) |
67 |
> |
68 |
|
69 |
Hi Kent, |
70 |
|
71 |
Thank yopu very much for your research and your explanations! :) |
72 |
|
73 |
Due to some statements I found online I did a interesting little |
74 |
experiment: |
75 |
|
76 |
fstrim |
77 |
fstrim |
78 |
reboot |
79 |
fstrim |
80 |
|
81 |
Reported amount of data for each fstrim: |
82 |
200.2GiB |
83 |
0.0GiB |
84 |
-- |
85 |
200.2GiB |
86 |
|
87 |
The reboot seems to be worth the same amount of fstrimmed |
88 |
data as one week of daily updates and recompilations. ;) |
89 |
|
90 |
(By the way: This all happens on a ext4 filesystem). |
91 |
|
92 |
Background according to the reports I found online: |
93 |
|
94 |
The kernel is keep track of all, which already has been fstrimmed and |
95 |
avoids to retrimm the same data. |
96 |
This knowledge gets lost, when the PC is powercycled or rebooted. |
97 |
|
98 |
I think, the value of the amount of fstrimmed data does not reflect |
99 |
the amount of data, which gets physically fstrimmed by the SSD |
100 |
controller. |
101 |
|
102 |
The kernel onlu throw the information of "possible candidates for |
103 |
being fstrimmed" towards the SSD controller, which is real master |
104 |
behind all this. |
105 |
|
106 |
And as you wrote: The maximum amount of "possible data for being |
107 |
fstrimmed" is all free space of the filesystem. |
108 |
|
109 |
Slightly related: |
110 |
Do you know the purpose of this value (smartctl -a <device>): |
111 |
Data Units Read: 656,599 [336 GB] |
112 |
Data Units Written: 702,251 [359 GB] |
113 |
Host Read Commands: 4,316,042 |
114 |
Host Write Commands: 3,080,180 |
115 |
|
116 |
Are these the raw amount of data, I have send to the SSD? |
117 |
Looks like a lot... |
118 |
|
119 |
Cheers! |
120 |
Meino |