On Thu, 4 Oct 2012, Andreas Hartmann wrote: > Date: Thu, 4 Oct 2012 06:47:36 +0200 > From: Andreas Hartmann <andihartmann@xxxxxxxxxxxxxxx> > To: util-linux@xxxxxxxxxxxxxxx > Subject: Questions concerning fstrim and online discard. > Resent-Date: Mon, 15 Oct 2012 16:10:43 +0200 > Resent-From: Karel Zak <kzak@xxxxxxxxxx> > Resent-To: Lukas Czerner <lczerner@xxxxxxxxxx> > > Hello! > > Please, may I ask you some questions because I'm a little bit confused > about the behaviour of fstrim and online discard (ext4)? > > > I'm using the following configuration / partitioning with a SSD > (Controller: SF-2281; Corsair Force GT 240GB): > > - dm_crypt: cryptsetup luksOpen - version 1.4.1, device-mapper > version 1.02.75 Hi Andreas, I hope that you realize that using discard with dm_crypt is not safe. > - lvm version 2.02.96 > - ext4, option discard; kernel version 3.4.11 > > All seems to work fine, I can't see any errors in messages or in dmesg > according trim / discard. The question is what kernel version do you use ? Currnently we will ignore all errors coming from the online discard including the situation where the device does not support discard. This is not exactly ideal, because we should really inform user that there was an error. However we should _NOT_ inform user about every discard request failed with EOPNOTSUPP because we can have multi-disk devices where some of the devices support discard and some of the does not, this is perfectly valid situation and kernel should not scream. Nevertheless I am going to change things so that we inform use about problem (other than EOPNOTSUPP). And maybe warn once a day that part, or whole device does not support discard at all - I think that this should not hurt. > > Now, I tested fstrim from util-linux version 2.19, and surprisingly got > this unexpected error: > > fstrim: /: FITRIM ioctl failed: Operation not supported Actually kernel version is what matters. > > Why do I get this error? Online discard always seemed to work fine (= I > didn't get any error). Those errors probably got silently dropped so you did not know about them. > > I detected, that there is another necessary option to get a > working fstrim: > cryptsetup luksOpen must be run with option --allow-discards. This is unsafe as I've mentioned earlier. Also it is necessary to actually allow the discard to be passed to the device and only with this option will fstrim and online discard actually do its work. > > > Now my questions: > - Did online discard work without --allow-discards? If not, why didn't I > get any error message? It does not. You did not noticed that because we were dropping this information, but I am going to change thing since this really might be a problem. > - Is there a difference between online discard and fstrim, means, > fstrim doesn't work without --allow-discards, but online discard does? Nope, not difference at all. Both methods are using the same kernel infrastructure the only difference is how it is used. > - fstrim / always says after each reboot: > /: 1701429248 bytes was trimmed > This can't be true as the root partition contains mainly root and > nothing else (no /var or /usr or even /opt). There has been no > changes in fs since last power on / off cycle and fstrim during the > last cycle. > Doesn't fstrim remember the already trimmed regions? Does it trim > always the complete unused regions? In ext4 we have optimization in place where we are trying to avoid discarding allocation groups which were discarded previously and no blocks were released from it since then. However this information does not survive umount/mount. This might change in the future, but currently we do not store such information on disk. > - Which trim should be used with a SF-2281 controller concerning > endurance? fstrim or online discard? As mentioned above, both methods uses the same interface. The difference is _how_ they use it. Online discard sends possibly big amount of relatively small discard requests with every journal commit provided that some block has been released. Simply it invokes discard every time blocks are freed. This might actually cause some performance issues because on some devices this might take relatively long time to finish and on SATA drives this is not queuable command. fstrim, or batched discard, on other hand can be invoked for example once a day not having any performance impact when it is not running. Generally I would consider fstrim to be the default option unless you're willing to benchmark your device to see how it performs with online discard (http://people.redhat.com/lczerner/discard/) > > > Thank you very much for your advice! > Kind regards, > Andreas I hope it helps. Thanks! -Lukas -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
