Editing ReiserFS (section)

===fsck===
ReiserFS 3's [[fsck]] is capable of rebuilding the whole tree as part of the rescue in case of its total corruption. This action has to be explicitly initiated by administrator and is not part of normal operation. Predictably, the process is destructive and may further corrupt existing files or introduce new entries with unexpected contents, which has been criticized as a less than optimal method.<ref>[http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.3/0219.html Theodore Ts'o LKML post]. Retrieved 5. July 2006</ref>

ReiserFS v3 images should not be stored on a ReiserFS v3 [[Disk partitioning|partition]] (e.g. backups or [[disk image]]s for emulators) without transforming them (e.g., by compressing or encrypting) in order to avoid confusing the rebuild. Reformatting an existing ReiserFS v3 partition can also leave behind data that could confuse the rebuild operation and make files from the old system reappear. This also allows malicious users to intentionally store files that will confuse the rebuilder. As the metadata is always in a consistent state after a file system check, ''corruption'' here means that contents of files are merged in unexpected ways with the contained file system's metadata. This is similar to the FSID problem in [[btrfs]]. The ReiserFS successor, Reiser4, fixes this problem.

ReiserFS in versions of the Linux kernel before 2.4.16 were considered unstable by Namesys and not recommended for production use, especially in conjunction with [[Network File System|NFS]].<ref>[http://namesys.com/download.html ReiserFS download page], see warning. Retrieved 5. July 2006</ref>

Early implementations of ReiserFS (prior to that in Linux 2.6.2) were also susceptible to out-of-order write hazards. But the current journaling implementation in ReiserFS is now on par with that of [[ext3]]'s "ordered" journaling level.{{Citation needed|date=August 2020}}