Welcome to the Reiser4 Wiki, the Wiki for users and developers of the ReiserFS and Reiser4 filesystems.

For now, most of the documentation is just a snapshot of the old Namesys site (archive.org, 2007-09-29).

There was also a Reiser4 Wiki (archive.org, 2007-07-06) once on pub.namesys.com.

Reiser4 discard support

From Reiser4 FS Wiki
(Difference between revisions)
Jump to: navigation, search
m (Update status of Precise discard in the page)
 
Line 33: Line 33:
 
[[PreciseDiscard|Precise discard]] is available with the patch against
 
[[PreciseDiscard|Precise discard]] is available with the patch against
 
reiser4-for-3.17.3, which can be found on
 
reiser4-for-3.17.3, which can be found on
[http://sourceforge.net/projects/reiser4/files/patches/ SourceForge].
+
[http://sourceforge.net/projects/reiser4/files/patches/3.17.3-reiser4-precise-discard-support.patch.gz SourceForge].
  
 
'''WARNING:''' Don't use it for important data for now. Even in the case
 
'''WARNING:''' Don't use it for important data for now. Even in the case

Latest revision as of 18:12, 3 February 2015

Starting from reiser4-for-3.16.2 SSD users can mount their reiser4 partitions with the option "discard" and the file system will issue discard requests to inform the device that blocks are not longer used.

In reiser4 issuing discard requests is a delayed action (like many other actions including block allocation, compression, etc). It means that discard requests are accumulated as the release of blocks and issued as background process after issuing of all other usual requests.

Such delayed technique allows to issue discard requests of better quality, because the discard requests get merged in the process of accumulation. Another advantage of the delayed discard is that the "non-queued TRIM" is not a problem for us.

[edit] Implementation details

Managing discard requests is a business of reiser4 transaction manager. This is because blocks deallocation is a kind of events which are tracked by the transaction manager. Deallocted extents are captured by a respective transaction atom. At commit time all the extents are sorted, merged and discarded right after overwriting journalled blocks at their permanent location on disk. After issuing the discard requests we complete the transaction by deallocating respective blocks at working bitmap (which always resides in memory). Thus, we guarantee consistency (nobody touches our extents before discard completion). We don't record information about discard extents in the journal. The worst thing that can happen after system crash is missing a number of discard requests. It doesn't break consistency of the file systems however. For such unpleasant situations we'll provide support of FITRIM ioctl later.

Precise discard is available with the patch against reiser4-for-3.17.3, which can be found on SourceForge.

WARNING: Don't use it for important data for now. Even in the case of no visible problems, please, check your partition by fsck.reiser4 as frequently as possible. Report about found inconsistency.


[edit] Discard support in reiser4progs

When formatting your SSD partition by mkfs.reiser4 use the option -d: it will issue discard request for the whole partition before creating reiser4 structure on it. This option is available in reiser4progs-1.0.9. In order to build reiser4progs-1.0.9 you will need libaal-1.0.6.

Personal tools