Minor change.

README.md

@@ -12,7 +12,7 @@ Various file system drivers support additional mount options to disable recovery
 Yet another way to mount a file system "read-only" is to mark a corresponding block device as read-only before running the *mount* command (using *blockdev* or *hdparm*, both programs do the same system call to mark a block device as read-only; command line examples: *blockdev --setro /dev/sda1; blockdev --setro /dev/sda* and *hdparm -r1 /dev/sda1; hdparm -r1 /dev/sda*). According to the man page (*man 8 hdparm*, the "-r" option):
 >-r   Get/set read-only flag for the device. When set, Linux disallows write operations on the device.
 
-Unfortunately, this facility wasn't implemented in a forensically sound way: it's up to a file system driver to check whether an underlying block device is marked as read-only and to refuse writing to that device. If a file system driver lacks these checks (e.g. due to a bug), a write request sent by this driver will hit a physical drive successfully passing through the block device driver. Several issues of this kind were discovered in the past: a kernel was writing the XFS superblock to a read-only block device, a kernel was removing orphan inodes from Ext3/4 file systems on read-only block devices. At present, it's known that Ext3/4 drivers will transfer the error code recorded in the journal (indicating a fatal error occurred within a file system) to the superblock even if the underlying block device is read-only. Many file system drivers supporting the batch discard feature allow userspace programs to discard the unused (free) space of a file system even when an underlying block device is read-only (this results in Trim commands hitting a physical drive).
+Unfortunately, this facility wasn't implemented in a forensically sound way: it's up to a file system driver to check whether an underlying block device is marked as read-only and to refuse writing to that device. If a file system driver lacks these checks (e.g. due to a bug), a write request sent by this driver will hit a physical drive successfully passing through the block device driver. Several issues of this kind were discovered in the past: a kernel was writing the XFS superblock to a read-only block device, a kernel was removing orphan inodes from Ext3/4 file systems on read-only block devices. At present, it's known that Ext3/4 drivers will transfer an error code recorded in the journal (indicating a fatal error occurred within the file system) to the superblock even if the underlying block device is read-only. Many file system drivers supporting the batch discard feature allow userspace programs to discard the unused (free) space of a file system even when an underlying block device is read-only (this results in Trim commands hitting a physical drive).
 
 Moreover, mounting a file system isn't the only dangerous action threatening the integrity of digital evidence. Modern Linux distributions automatically activate Linux RAID, fake RAID and LVM volumes. These actions are subject to the same issues as described above: for example, LVM driver will sync two RAID1-like volumes if they are out of sync, and this will happen to read-only block devices too. Note this when doing data recovery!