1 |
On Tue, May 19, 2015 at 11:22 AM, <gottlieb@×××.edu> wrote: |
2 |
> On Tue, May 19 2015, Peter Humphrey wrote: |
3 |
> |
4 |
>> On Tuesday 19 May 2015 10:53:26 Rich Freeman wrote: |
5 |
>>> On Tue, May 19, 2015 at 10:44 AM, Peter Humphrey <peter@××××××××××××.uk> |
6 |
>> wrote: |
7 |
>>> > Incidentally, what's the received wisdom on frequency of file-system |
8 |
>>> > trimming on SSDs these days? I've seen values quoted between twice a day |
9 |
>>> > and once a week. And how does trimming affect btrfs? |
10 |
> |
11 |
> I included "discard" in fstab for my ssd filesystems, presumably |
12 |
> following some installation guide. For example I have |
13 |
> |
14 |
> /dev/sda5 / ext4 noatime,discard 0 1 |
15 |
> /dev/vg/local /local ext4 noatime,discard 0 2 |
16 |
> |
17 |
> Is it preferred to instead issue explicit trim's via cron? |
18 |
> |
19 |
|
20 |
It depends. |
21 |
|
22 |
In theory giving your drive useful information about allocation now is |
23 |
better than giving it the information later. The drive can make use |
24 |
of that information to improve performance. |
25 |
|
26 |
In practice some drives have brain-dead firmware and they'll do stupid |
27 |
things with that information. If you trim part of an erase block, the |
28 |
drive should just file that info away and make use of that information |
29 |
when it can. However, some drives will immediately copy/erase the |
30 |
rest of the block at that moment, which creates an unnecessary erase |
31 |
cycle and creates IO load at a moment that the drive is already busy. |
32 |
|
33 |
So, if your drive isn't brain-dead discard is better. If your drive |
34 |
is brain-dead fstrim is almost as good if the drive isn't too full. |
35 |
I've yet to test discard and see how well it works. |
36 |
|
37 |
-- |
38 |
Rich |