Difference between revisions of "Check Disk Filesystems"

From unRAID
Jump to: navigation, search
(update for v5 Maintenance Mode)
Line 44: Line 44:
  mount /dev/md1 /mnt/disk1          ''[important to match up the 'md1' with 'disk1', 'md2' with 'disk2', etc.]''
  mount /dev/md1 /mnt/disk1          ''[important to match up the 'md1' with 'disk1', 'md2' with 'disk2', etc.]''
  /usr/sbin/smbd -D
  samba start                        ''[all shares should again be visible]''
/usr/sbin/nmbd -D                  ''[all shares should again be visible]''

Revision as of 18:48, 7 February 2013

The reiserfsck tool is designed to check and optionally fix the Reiser file system integrity of a data drive, while maintaining its parity info. UnRAID data disks are formatted with ReiserFS version 3.6.

The reiserfsck tool is only for the maintenance and correction of file system issues, NOT for hardware or other issues. If you have hardware issues, such as disk errors, then you need to check the syslog for the type of disk errors, and obtain SMART reports for the drive. Please see the Troubleshooting page, especially the Troubleshooting#Obtaining a SMART report section.

Very important!!! Do NOT run reiserfsck on the parity drive. It does NOT have a file system, and running reiserfsck on your parity drive can corrupt it!

Note: the following examples refer to Disk 1, as /dev/md1. You will need to substitute the correct drive for each case. For example, if it is your Disk 5 that you are testing, then substitute md5 for md1, and disk5 for disk1, in all of the instructions below.

Preparing to run reiserfsck

If you are running UnRAID v5.0-beta8d or later, then start the array in Maintenance mode, by clicking the Maintenance mode check box before clicking the Start button. This starts the UnRAID driver but does not mount any of the drives.

Otherwise, if you are running an UnRAID version 4 or version 5 up to v5.0-beta8c, start the array and then, from the console or in a Telnet session, type this:

cd                   [this will make sure you are in the /root directory]
samba stop           [all your shares will disappear from network]
umount /dev/md1      ['md1' corresponds to disk1, 'md2' to disk2, etc.  note: it is 'umount', not 'unmount']

Note: you will not be able to unmount the disk if it is "busy." A disk is busy if any processes are using it, or referencing files/folders on it. If the "umount" command is not successful, you will need to stop any add-on process you might have running that are referencing the disk before you can unmount it. If you have "changed directory" to it, you must log off, or "cd" elsewhere (off the disk) before the "umount" will succeed.

Running reiserfsck

Now you are ready to run the Reiser file system test. (Note: --check is the default option, not strictly required, but included here for clarification.) At the console or in a Telnet session, type this:

reiserfsck --check /dev/md1  [answer with the word Yes when prompted, do not type yes or YES, but Yes (capital Y and lower case es)]

At the conclusion of the reiserfsck --check command, a report will be output. If errors are detected, this report may specify an additional action to take. The most common ones are to re-run reiserfsck specifying the --fix-fixable switch or the --rebuild-tree switch, for example:

reiserfsck --fix-fixable /dev/md1  [answer with Yes when prompted. (capital Y and lower case es)]

If your file system has only minor issues, then running reiserfsck --fix-fixable should be all that is necessary.

Important Note!!! Do NOT run reiserfsck with the --rebuild-sb or --rebuild-tree switches, unless you are instructed to, by the instruction of a previous run of reiserfsck, or by an expert user! They are last-resort options, to repair a severely damaged Reiser file system, and recover as much as possible. They almost always create a lost+found directory and place in it the files, directories, and parts of files it can recover. It will then be up to you to rename them and restore those files and directories to their correct locations. Many times it will be possible to identify them by their contents, or their size.

Important Note #2!!! If the option --rebuild-sb is suggested, then PLEASE ask for assistance on the unRAID forums. The --rebuild-sb option requires answers that must be PERFECT. Please see this thread, and this too.

Note: If reiserfsck performs write operations to repair the file system, the array parity will be maintained.

After running reiserfsck

If you are running UnRAID v5.0-beta8d or later and are in Maintenance mode, you can resume normal operations by stopping the array, then restarting the array with the Maintenance mode check box unchecked.

Otherwise, if you are running UnRAID version 4 or version 5 up to v5.0-beta8c, you can resume normal operations by, from the console or in a Telnet session, typing this:

mount /dev/md1 /mnt/disk1          [important to match up the 'md1' with 'disk1', 'md2' with 'disk2', etc.]
samba start                        [all shares should again be visible]

Additional comments

The reiserfsck tool may take a long time on a full file system (several minutes to a half hour, or more). Also re-mounting the disk can take up to 15 seconds or so.

If you were instructed to use special parameters such as --fix-fixable and --rebuild-tree, then it is possible that some files were not completely recovered. Check for a lost+found folder on this drive, which may contain fragments of the unrecoverable files. It is unfortunately up to you to examine these and determine what files they are from, and act accordingly. Hopefully, you have another copy of each file. When you are finished examining them and saving what you can, then delete the fragments and remove the lost+found folder. Dealing with this folder does not have to be done immediately. This is similar to running chkdsk or scandisk within Windows, and finding lost clusters, and dealing with files named File0000.chk or similar. You may find one user's story very helpful, plus his later tale of the problems of sifting through the recovered files.

If you get an error that says reiserfs_open: the reiserfs superblock cannot be found on /dev/sdX. Failed to open the filesystem. it usually indicates you attempted to run the file system check on the wrong device name. For almost all repairs, you would use /dev/md1, /dev/md2, /dev/md3, /dev/md4, etc. If operating on the cache drive that is not protected by parity you would use /dev/sdX1 (note the trailing "1" indicating the first partition on the cache drive)