[haiku-commits] Re: BRANCH axeld-github.trim [1c6edcd] src/add-ons/kernel/file_systems/bfs src/bin headers/private/fs_shell headers/os/drivers build/jam

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 05 Aug 2013 01:18:05 +0200

On 08/05/2013 12:46 AM, Ingo Weinhold wrote:
On 08/05/2013 12:30 AM, axeld-github.trim wrote:
be4f73b: Added fstrim command.

   Later, there should be a service that runs this from time to time
for all
   devices that support it.

That seems a bit crude. Wouldn't it be preferable to do the trimming
on-the-fly as needed? I.e. when a file is removed the file system should
know which blocks can be trimmed. If this is problematic with respect to
performance a service could be provided to buffer the trim requests.

This is actually how Linux does it which I figure is good enough for us :-)

Linux also supports discarding the blocks directly, but that seems to have a great impact on file system speed. At least the numbers I found on the net seems to suggest that, see for example [1], respectively the links found in there [2], [3].

Buffering the blocks to be trimmed is problematic, as you will need to check whether they are still available when you get to trim them, plus this info won't survive a reboot.

Do you have a better idea in this light?

Bye,
   Axel.

[1] http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/
[2] https://patrick-nagel.net/blog/archives/337
[3] http://oss.sgi.com/pipermail/xfs/2011-November/015320.html


Other related posts: