Showing posts with label RAID. Show all posts
Showing posts with label RAID. Show all posts

Friday, August 3, 2012

RAID: Why and When

— SkyHi @ Friday, August 03, 2012

RAID stands for Redundant Array of Independent Disks (some are taught "Inexpensive" to indicate that they are "normal" disks; historically there were internally redundant disks which were very expensive; since those are no longer available the acronym has adapted).
At the most general level, a RAID is a group of disks that act on the same reads and writes. SCSI IO is performed on a volume ("LUN"), and these are distributed to the underlying disks in a way that introduces a performance increase and/or a redundancy increase. The performance increase is a function of striping: data is spread across multiple disks to allow reads and writes to use all the disks' IO queues simultaneously. Redundancy is a function of mirroring. Entire disks can be kept as copies, or individual stripes can be written multiple times. Alternatively, in some types of raid, instead of copying data bit for bit, redundancy is gained by creating special stripes that contain parity information, which can be used to recreate any lost data in the event of a hardware failure.
There are several configurations that provide different levels of these benefits, which are covered here, and each one has a bias toward performance, or redundancy.
An important aspect in evaluating which RAID level will work for you depends on its advantages and hardware requirements (E.g.: number of drives).
Another important aspect of most of these types of RAID (0,1,5) is that they do not ensure the integrity of your data, because they are abstracted away from the actual data being stored. So RAID does not protect against corrupted files. If a file is corrupted by any means, the corruption will be mirrored or paritied and committed to the disk regardless. However, RAID-Z does claim to provide file-level integrity of your data.

Direct attached RAID: Software and Hardware

There are two layers at which RAID can be implemented on direct attached storage: hardware and software. In true hardware RAID solutions, there is a dedicated hardware controller with a processor dedicated to RAID calculations and processing. It also typically has a battery-backed cache module so that data can be written to disk, even after a power failure. This helps to eliminate inconsistencies when systems are not shut down cleanly. Generally speaking, good hardware controllers are better performers than their software counterparts, but they also have a substantial cost and increase complexity.
Software RAID typically does not require a controller, since it doesn't use a dedicated RAID processor or a separate cache. Typically these operations are handled directly by the CPU. In modern systems, these calculations consume minimal resources, though some marginal latency is incurred. RAID is handled by either the OS directly, or by a faux controller in the case of FakeRAID.
Generally speaking, if someone is going to choose software RAID, they should avoid FakeRAID and use the OS-native package for their system such as Dynamic Disks in Windows, mdadm/LVM in Linux, or ZFS in Solaris, FreeBSD, and other related distributions. FakeRAID use a combination of hardware and software which results in the initial appearance of hardware RAID, but the actual performance of software RAID. Additionally it is commonly extremely difficult to move the array to another adapter (should the original fail).

Centralized Storage

The other place RAID is common is on centralized storage devices, usually called a SAN (Storage Area Network) or a NAS (Network Attached Storage). These devices manage their own storage and allow attached servers to access the storage in various fashions. Since multiple workloads are contained on the same few disks, having a high level of redundancy is generally desirable.
The main difference between a NAS and a SAN is block vs. file system level exports. A SAN exports a whole "block device" such as a partition or logical volume (Including those built on top of a RAID array.). Examples of SAN's include Fibre Channel and iSCSI. A NAS exports a "file system" such as a file or folder. Examples of NAS's include CIFS/SMB (Windows file sharing) and NFS.

RAID 0

Good when: Speed at all costs!

Bad when: You care about your data.

RAID0 (aka Striping) is sometimes referred to as "the amount of data you will have left when a drive fails". It really runs against the grain of "RAID", where the "R" stands for "Redundant".
RAID0 takes your block of data, splits it up into as many pieces as you have disks (2 disks → 2 pieces, 3 disks → 3 pieces) and then writes each piece of the data to a seperate disk.
This means that a single disk failure destroys the entire array (because you have Part 1 and Part 2, but no Part 3), but it provides very fast disk access.
It is not often used in production environments, but it could be used in a situation where you have strictly temporary data that can be lost without repercussions. It is used somewhat commonly for caching devices (such as an L2Arc device).
The total usable disk space is the sum of all the disks in the array added together (e.g. 3x 1TB disks = 3TB of space)
RAID 1

RAID 1

Good when: You have limited number of disks but need redundancy

Bad when: You need a lot of storage space

RAID 1 (aka Mirroring) takes your data and duplicates it identically on two or more disks (although typically only 2 disks). It is the only way to ensure data redundancy when you have less than three disks.
RAID 1 sometimes improves read performance. Some implementations of RAID 1 will read from both disks to double the read speed. Some will only read from one of the disks, which does not provide any additional speed advantages. Others will read the same data from both disks, ensuring the array's integrity on every read, but this will result in the same read speed as a single disk.
It is typically used in small servers that have very little disk expansion, such as 1RU servers that may only have space for two disks or in workstations that require redundancy. Because of its high overhead of "lost" space, it can be cost prohibitive with small-capacity, high-speed (and high-cost) drives, as you need to spend twice as much money to get the same level of usable storage.
The total usable disk space is the size of the smallest disk in the array (e.g. 2x 1TB disks = 1TB of space).
RAID 1

RAID 1E

The 1E RAID level is similar to RAID 1 - data is always written to (at least) two disks. But unlike RAID1, it allows for an odd number of disks by simply interleaving the data blocks among several disks.
Performance characteristics are similar to RAID1, fault tolerance is similar to RAID 10.
RAID 1E

RAID 10

Good when: You want speed and redundancy

Bad when: You can't afford to lose half your disk space

RAID 10 is a combination of RAID 1 and RAID 0. The order of the 1 and 0 is very important. Say you have 8 disks, it will create 4 RAID 1 arrays, and then apply a RAID 0 array on top of the 4 RAID 1 arrays. It requires at least 4 disks, and additional disks have to be added in pairs.
This means that one disk from each pair can fail. So if you have sets A, B, C and D with disks A1, A2, B1, B2, C1, C2, D1, D2, you can lose one disk from each set (A,B,C or D) and still have a functioning array.
However, if you lose two disks from the same set, then the array is totally lost. You can lose up to (but not guaranteed) 50% of the disks.
You are guaranteed high speed and high availability in RAID 10.
RAID 10 is a very common RAID level, especially with high capacity drives where a single disk failure makes a second disk failure more likely before the RAID array is rebuilt. During recovery, the performance degradation is much lower than its RAID 5 counterpart as it only has to read from one drive to reconstruct the data.
The avaliable disk space is 50% of the sum of the total space. (e.g. 8x 1TB drives = 4TB of usable space). If you use different sizes, only the smallest size will be used from each disk.
RAID 10

RAID 01

Good when: never

Bad when: always

It is the reverse of RAID 10. It creates two RAID 0 arrays, and then puts a RAID 1 over the top. This means that you can lose one disk from each set (A1, A2, A3, A4 or B1, B2, B3, B4).
To be absolutely clear:
  • If you have a RAID10 array with 8 disks and one dies (we'll call it A1) then you'll have 6 redundant disks and 1 without redundancy. If another disk dies there's a 85% chance your array is still working.
  • If you have a RAID01 array with 8 disks and one dies (we'll call it A1) then you'll have 4 redundant disks and 3 without redundancy. If another disk dies there's a 57% chance your array is still working.
It provides no additional speed over RAID 10, but substantially less redundancy and should be avoided at all costs.

RAID 5

Good when: You want a balance of redundancy and disk space or have a large sequential write workload.

Bad when: You have a high random write workload or large drives.

RAID 5 uses a simple XOR operation to calculate parity. Upon single drive failure, the information can be reconstructed from the remaining drives using the XOR operation on the known data.
However, this rebuilding process is very intensive and array performance can suffer heavily during the rebuild procedure. Given the lengthy amount of time it takes to perform this rebuild (days!) it is not usually recommended to use RAID5 on large drives, as the risk of data loss during a rebuild is increased relative to disk size. Because every sector on every disk is needed to calculate the data to be rebuilt on the replaced disk, there is an increased risk of data loss from an already present but previously undetected error, or a new failure from the stress of the rebuild, on one of those disks - either in the form of an unrecoverable read error, or silent data corruption (bit flipping).
Another caveat is the "write hole," which describes a condition where a failure of some kind (power, system, RAID controller, etc.) occurs mid-write, with new data being written to some, but not all, of a parity stripe. In this situation, it's not clear to the device what data can be trusted and what cannot - the entire stripe is rendered corrupt. Battery-backed write caches on RAID controllers are the main mitigation technique for this issue.
RAID 5 has a high disk write overhead on small writes. Writes less than a stripe width in size cause an extra read prior to the write, causing a single frontend IOP to turn into 4 backend IOPs. The small write penalty is mitigated by having controller-based write-back caches capable of taking up the entire I/O write load of your system. However, once the cache fills up (or crams), all activity on the array will cease until enough data has been synced do the disks. RAID5 can also give better performance than RAID10 for large sequential writes since it has more spindles to distribute writes onto. The computational overhead of the parity calculation is hardly a concern nowadays - hardware I/O processors used in more recent RAID controllers are capable of calculating parity at full wirespeed of the interface.
However, RAID 5 is the most cost effective solution of adding redundant storage to an array, as it requires the loss of only 1 disk (E.g. 4x 1TB disks = 3TB of usable space). It requires a minimum of 3 disks.
There has been a lot of controversy about striping with parity in the past, many people regard it not being worth the money if you need high array performance in terms of IOPS - which is a typical requirement for database applications or SAN systems used for virtualization. The Battle Against Any RAID Five (BAARF) initiative website provides a lot of information about the internal workings of striping with parity and its caveats.
RAID 5

RAID 6

Good when: You want a balance of redundancy and disk space or have a large sequential write workload.

Bad when: You have a high random write workload.

RAID 6 is similar to RAID 5 but it uses two disks worth of parity instead of just one (the first is XOR, the second is a LSFR), so you can lose two disks from the array with no data loss. The write penalty is higher than RAID 5 and you have one less disk of space, so this option is best geared towards arrays that do a lot of reads or large sequential writes and when RAID 10 isn't an option because of capacity.
RAID 6

RAID 50

Good when: You have a lot of disks that need to be in a single array and RAID 10 isn't an option because of capacity.

Bad when: You have so many disks that many simultaneous failures are possible before rebuilds complete. Or when you don't have many disks.

RAID 50 is a nested level, much like RAID 10. It combines two or more RAID 5 arrays and stripes data across them in a RAID 0. This offers both performance and multiple disk redundancy, as long as multiple disks are lost from different RAID 5 arrays.
In a RAID 50, disk capacity is n-x, where x is the number of RAID 5s that are striped across. For example, if a simple 6 disk RAID 50, the smallest possible, if you had 6x1TB disks in two RAID 5s that were then striped across to become a RAID 50, you would have 4TB usable storage.

RAID 60

Good when: You have a similar use case to RAID 50, but need more redundancy.

Bad when: You don't have a substantial number of disks in the array.

RAID 6 is to RAID 60 as RAID 5 is to RAID 50. Essentially, you have more than one RAID 6 that data is then striped across in a RAID 0. This setup allows for up to two members of any individual RAID 6 in the set to fail without data loss. Rebuild times for RAID 60 arrays can be substantial, so it's usually a good idea to have one hot-spare for each RAID 6 member in the array.
In a RAID 60, disk capacity is n-2x, where x is the number of RAID 6s that are striped across. For example, if a simple 8 disk RAID 60, the smallest possible, if you had 8x1TB disks in two RAID 6s that were then striped across to become a RAID 60, you would have 4TB usable storage. As you can see, this gives the same amount of usable storage that a RAID 10 would give on an 8 member array. While RAID 60 would be slightly more redundant, the rebuild times would be substantially larger. Generally, you want to consider RAID 60 only if you have a large number of disks.

RAID-Z

Good when: You are using ZFS on a system that supports it.

Bad when: Performance demands hardware RAID acceleration.

RAID-Z is a bit complicated to explain since ZFS radically changes how storage and file systems interact. ZFS encompasses the traditional roles of volume management (RAID is a function of a Volume Manager) and file system. Because of this, ZFS can do RAID at the file's storage block level rather than at the volume's strip level. This is exactly what RAID-Z does, write the file's storage blocks across multiple physical drives including a parity block for each set of stripes.
An example may make this much more clear. Say you have 3 disks in a ZFS RAID-Z pool, the block size is 4KB. Now you write a file to the system that is exactly 16KB. ZFS will split that into four 4KB blocks (as would a normal operating system); then it will calculate two blocks of parity. Those six blocks will be placed on the drives similar to how RAID-5 would distribute data and parity. This is an improvement over RAID5 in that there was no reading of existing data stripes to calculate the parity.
Another example builds on the previous. Say the file was only 4KB. ZFS will still have to build one parity block, but now the write load is reduced to 2 blocks. The third drive will be free to service any other concurrent requests. A similar effect will be seen anytime the file being written is not a multiple of the pool's block size multiplied by the number of drives less one (ie [File Size] <> [Block Size] * [Drives - 1]).
ZFS handling both Volume Management and File System also means you don't have to worry about aligning partitions or stripe-block sizes. ZFS handles all that automatically with the recommended configurations.
The nature of ZFS counteracts some of the classic RAID-5/6 caveats. All writes in ZFS are done in a copy-on-write fashion; all changed blocks in a write operation are written to a new location on disk, instead of overwriting the existing blocks. If a write fails for any reason, or the system fails mid-write, the write transaction either occurs completely after system recovery (with the help of the ZFS intent log) or does not occur at all, avoiding potential data corruption. Another issue with RAID-5/6 is potential data loss or silent data corruption during rebuilds; regular zpool scrub operations can help to catch data corruption or drive issues before they cause data loss, and checksumming of all data blocks will ensure that all corruption during a rebuild is caught.
The main disadvantage to RAID-Z is that it is still software raid (and suffers from the same minor latency incurred by the CPU calculating the write load instead of letting a hardware HBA offload it). This may be resolved in the future by HBA's that support ZFS hardware acceleration.


REFERENCES
http://serverfault.com/questions/339128/what-are-the-different-widely-used-raid-levels-and-when-should-i-consider-them

Thursday, September 29, 2011

Move Web Directory to Raid Array

— SkyHi @ Thursday, September 29, 2011
Question:
I want to improve the performance of a web application running on Apache, so I created a Raid Array on /dev/md0.
Now I need to figure out how to move the application to the array and make sure that Apache will still serve it when someone accesses my domain.
Web application is in the directory: /var/www/html - Raid Array device is: /dev/md0

Answer:
Copy all of your files to the new device, stop apache, then mount the new device on top of your existing /var/www/html and restart apache.
mount /dev/md0 /mnt
cp -r /var/www/html/* /mnt 
umount /mnt
service httpd stop
mount /dev/md0 /var/www/html
service httpd start
You would then need to ensure it's mounted at boot by editing the /etc/fstab
/dev/md0    /var/www/html ....
 
REFERENCES
http://serverfault.com/questions/316891/move-web-directory-to-raid-array

Wednesday, July 6, 2011

Trouble partioning and formatting new hard drive

— SkyHi @ Wednesday, July 06, 2011
I'm new to Linux and I recently installed Fedora Core 6 and MythTV (kernel 2.6.18-1.2868.fc6). I have an existing Western Digital SATA 120 GB hard drive
and I'm attempting to add an additional Western Digital SATA 250 GB drive. I've been trying to partion and format the new drive using fdisk and mkfs but have been having trouble. In particular, I have attempted the following:




Code:

[root@localhost mnt]# fdisk /dev/sdb

The number of cylinders for this disk is set to 30401.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       30401   244196001   85  Linux extended

Command (m for help): d
Selected partition 1

Command (m for help): p

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
e
Partition number (1-4): 1
First cylinder (1-30401, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-30401, default 30401):
Using default value 30401

Command (m for help): p

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       30401   244196001    5  Extended

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 85
Changed system type of partition 1 to 85 (Linux extended)

Command (m for help): p

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       30401   244196001   85  Linux extended

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@localhost mnt]# fdisk /dev/sdb

The number of cylinders for this disk is set to 30401.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       30401   244196001   85  Linux extended

Command (m for help): q

[root@localhost mnt]# mkfs -t ext3 /dev/sdb1
mke2fs 1.39 (29-May-2006)
/dev/sdb1: Invalid argument passed to ext2 library while setting up superblock
[root@localhost mnt]#

I'm getting the "/dev/sdb1: Invalid argument passed to ext2 library while setting up superblock" error when I try to format the new partition. What am I doing wrong?

syg00
Extended partition is a container for logical(s) - you can't use it
(directly) for data. Go back in and create a logical partition within
that extended, and use that. BTW, you can have multiple logicals; the
first logical doesn't have to use all the space.

bigrigdriver
If I read all this correctly, you have created an extended partition on sdb. Extended partitions are a device for getting around the limitation of 4 primary partitions listed in the MBR. They are containers which will be counted as primary partitions for MBR purposes.



After creating the extended partition, it is then necessary to create logical partitions inside the extended partition, and format those logical partitions. Then you can install operating systems or write files to the logical partitions.



Basically, you have gone part-way to doing what you want to do. Not go back to fdisk (or cfdisk) and create logical partitions inside the extended partition.

stress_junkie

syg00 and bigrigdriver, your diagnosis is correct but your remediation plan is terrible. Why keep an extended partition when there isn't even a single primary partition?



netrambler, the partition type should be 83 not 85. Also if your system has the cfdisk utility you would probably be happier using that than to use the fdisk utility. cfdisk has an ncurses graphical display. (ncurses is a library to create lines and position the cursor on text terminals or terminal windows.)




Code:

cfdisk /dev/sdb

Use the up/down arrow keys to select the existing partition. Use the right/left arrow keys to select [DELETE] and then press the Enter key. Then select [NEW] and press Enter. Use the default start point and size and press Enter. Use the arrow keys to select [TYPE] and press Enter. Make the partition type 83. Then use the arrow keys to select [WRITE]. Write the new partition table to the disk. Then exit from cfdisk.



Check your work by using the fdisk utility with the -l parameter.


Code:

fdisk -l

You will see a listing of partitions for both of your disks. The new partition on /dev/sdb should be identified as a Linux primary partition. If everything looks good then format the new disk partition as you had already attempted to do.


Code:

mkfs -t ext3 /dev/sdb1

netrambler Original Poster





I think I got it to work. I did the following:




Code:

[root@localhost boot]# fdisk /dev/sdb<br /><br />The number of cylinders for this disk is set to 30401.<br />There is nothing wrong with that, but this is larger than 1024,<br />and could in certain setups cause problems with:<br />1) software that runs at boot time (e.g., old versions of LILO)<br />2) booting and partitioning software from other OSs<br />   (e.g., DOS FDISK, OS/2 FDISK)<br /><br />Command (m for help): m<br />Command action<br />   a   toggle a bootable flag<br />   b   edit bsd disklabel<br />   c   toggle the dos compatibility flag<br />   d   delete a partition<br />   l   list known partition types<br />   m   print this menu<br />   n   add a new partition<br />   o   create a new empty DOS partition table<br />   p   print the partition table<br />   q   quit without saving changes<br />   s   create a new empty Sun disklabel<br />   t   change a partition's system id<br />   u   change display/entry units<br />   v   verify the partition table<br />   w   write table to disk and exit<br />   x   extra functionality (experts only)<br /><br />Command (m for help): p<br /><br />Disk /dev/sdb: 250.0 GB, 250059350016 bytes<br />255 heads, 63 sectors/track, 30401 cylinders<br />Units = cylinders of 16065 * 512 = 8225280 bytes<br /><br />   Device Boot      Start         End      Blocks   Id  System<br />/dev/sdb1               1       30401   244196001   85  Linux extended<br /><br />Command (m for help): d<br />Selected partition 1<br /><br />Command (m for help): p<br /><br />Disk /dev/sdb: 250.0 GB, 250059350016 bytes<br />255 heads, 63 sectors/track, 30401 cylinders<br />Units = cylinders of 16065 * 512 = 8225280 bytes<br /><br />   Device Boot      Start         End      Blocks   Id  System<br /><br />Command (m for help): w<br />The partition table has been altered!<br /><br />Calling ioctl() to re-read partition table.<br />Syncing disks.<br />[root@localhost boot]#<br />[root@localhost boot]# fdisk /dev/sdb<br /><br />The number of cylinders for this disk is set to 30401.<br />There is nothing wrong with that, but this is larger than 1024,<br />and could in certain setups cause problems with:<br />1) software that runs at boot time (e.g., old versions of LILO)<br />2) booting and partitioning software from other OSs<br />   (e.g., DOS FDISK, OS/2 FDISK)<br /><br />Command (m for help): m<br />Command action<br />   a   toggle a bootable flag<br />   b   edit bsd disklabel<br />   c   toggle the dos compatibility flag<br />   d   delete a partition<br />   l   list known partition types<br />   m   print this menu<br />   n   add a new partition<br />   o   create a new empty DOS partition table<br />   p   print the partition table<br />   q   quit without saving changes<br />   s   create a new empty Sun disklabel<br />   t   change a partition's system id<br />   u   change display/entry units<br />   v   verify the partition table<br />   w   write table to disk and exit<br />   x   extra functionality (experts only)<br /><br />Command (m for help): p<br /><br />Disk /dev/sdb: 250.0 GB, 250059350016 bytes<br />255 heads, 63 sectors/track, 30401 cylinders<br />Units = cylinders of 16065 * 512 = 8225280 bytes<br /><br />   Device Boot      Start         End      Blocks   Id  System<br /><br />Command (m for help): n<br />Command action<br />   e   extended<br />   p   primary partition (1-4)<br />p<br />Partition number (1-4): 1<br />First cylinder (1-30401, default 1):<br />Using default value 1<br />Last cylinder or +size or +sizeM or +sizeK (1-30401, default 30401):<br />Using default value 30401<br /><br />Command (m for help): p<br /><br />Disk /dev/sdb: 250.0 GB, 250059350016 bytes<br />255 heads, 63 sectors/track, 30401 cylinders<br />Units = cylinders of 16065 * 512 = 8225280 bytes<br /><br />   Device Boot      Start         End      Blocks   Id  System<br />/dev/sdb1               1       30401   244196001   83  Linux<br /><br />Command (m for help): w<br />The partition table has been altered!<br /><br />Calling ioctl() to re-read partition table.<br />Syncing disks.<br />[root@localhost boot]# mkfs -t ext3 /dev/sdb1<br />mke2fs 1.39 (29-May-2006)<br />Filesystem label=<br />OS type: Linux<br />Block size=4096 (log=2)<br />Fragment size=4096 (log=2)<br />30539776 inodes, 61049000 blocks<br />3052450 blocks (5.00%) reserved for the super user<br />First data block=0<br />Maximum filesystem blocks=0<br />1864 block groups<br />32768 blocks per group, 32768 fragments per group<br />16384 inodes per group<br />Superblock backups stored on blocks:<br />        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,<br />        4096000, 7962624, 11239424, 20480000, 23887872<br /><br />Writing inode tables: done<br />Creating journal (32768 blocks): done<br />Writing superblocks and filesystem accounting information: done<br /><br />This filesystem will be automatically checked every 29 mounts or<br />180 days, whichever comes first.  Use tune2fs -c or -i to override.<br />[root@localhost boot]#<br />[root@localhost boot]# cd /mnt<br />[root@localhost mnt]# ls<br />common  sdb1  video_ext<br />[root@localhost mnt]# mount -t ext3 /dev/sdb1 /mnt/video_ext<br />[root@localhost mnt]# ls<br />common  sdb1  video_ext<br />[root@localhost mnt]# cd video_ext<br />[root@localhost video_ext]# ls<br />lost+found

I'll let you know if I have any problems. Thanks for the help!

stress_junkie
If you want the new disk partition to automatically mount when the operating system
starts you can put a line in the file /etc/fstab as follows:


Code:

/dev/sdb1   /mnt/video_ext   auto   defaults   0 0

If you want to increase the security of your system my making it impossible to run programs on this disk partition then use this line:


Code:

/dev/sdb1  /mnt/video_ext  auto  defaults,noexec  0 0

Using the noexec option means that even if there is a program on that disk you cannot run it. That is good for security. You can do the same thing with any disk partition. One good idea is to have a partition for your /home directory and then to mount that using the noexec option. That can prevent malicious Java scripts from copying a program to your home directory and running it.



That's just one of many things that you can do to enhance security.

REFERENCES
http://www.linuxquestions.org/questions/linux-general-1/trouble-partioning-and-formatting-new-hard-drive-515018/

Friday, December 31, 2010

What is better LVM on RAID or RAID on LVM?

— SkyHi @ Friday, December 31, 2010

QUESTION:

I currently have LVM on software RAID, but I'd like to ask you what you think it is better solution, maybe some pros and cons?



Edit: It is about software raid on lvm or lvm on software raid. I know than hardware raid is better if we are thinking about performance.

ANSWER:

1.You're current setup is like this:



<code>| / | /var | /usr | /home  |
--------------------------
| LVM Volume |
--------------------------
| RAID Volume |
--------------------------
| Disk 1 | Disk 2 | Disk 3 |
</code>


It's a much simpler setup with more flexibility. You can use all of the disks in the RAID volume and slice and dice them whatever way you like with LVM. The other way isn't even worth thinking about - it's ridiculously complicated and you lose the benefits of LVM at the filesystem level.



If you tried to RAID LVM volumes, you're left with a normal device without any of the LVM volume benefits (e.g. growing filesystems etc.)


2.have hardware raid and you can have lvm on top - best combination.

3.Your current setup is fine. This is the recommended way to do it.



Raid deals with keeping the bits secure/redundant/fast/whatever and LVM helps you present them in a esasy to use way.


REFERENCES
http://serverfault.com/questions/217666/what-is-better-lvm-on-raid-or-raid-on-lvm






Saturday, November 13, 2010

CentOS / Redhat: Create Software RAID 1 Array

— SkyHi @ Saturday, November 13, 2010
Recently, I've added another 73GB SAS disk to my Linux server after the installation. I've 30GB empty partition on old hard disk. How do I convert old /dev/sda3 and new /dev/sdb1 (both 30GB) into RAID 1 to improve NFS server speed and reliability?

RAID devices are virtual devices created from two or more real block devices. Linux supports RAID1 and other levels. You need to have same size partition on both disks i.e. on second disk create partitions exactly the same size as those on the first disk, and set the type as fd (Linux raid autodetect). You need to use the following commands to create RAID 1.
WARNING! These examples may crash your computer or may result into data loss if not executed properly. These examples involves disk partition manipulation using the fdisk command and building (formatting) file systems using the mkfs.ext3 command. So make sure you backup all data before typing any one of the following command.
Our sample RAID -1 setup with two partitions:
+------------+
|            |
| /dev/sda3  | ===============+
|            |                |
+------------+                |
  37GB                        | =======> RAID-1 /dev/md0
                              |
+------------+                |
|            |                |
| /dev/sdb1  | ===============+
|            |
+------------+
  37GB

Step # 1: List Partitions

Type the following commands:
# fdisk -l
# fdisk -l /dev/sda

Sample outputs:
Disk /dev/sda: 73.2 GB, 73295462400 bytes
255 heads, 63 sectors/track, 8910 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        3929    31455270   83  Linux
/dev/sda3            3930        8779    38957625   83  Linux
/dev/sda4            8780        8910     1052257+   5  Extended
/dev/sda5            8780        8910     1052226   82  Linux swap / Solaris
For example, purpose you will use /dev/sda3 (size 37G). Now, list second disk partitions, enter:
# fdisk -l /dev/sdb
Sample outputs:
Disk /dev/sdb: 73.2 GB, 73295462400 bytes
255 heads, 63 sectors/track, 8910 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Step # 2: Create 37G Partitions For /dev/sdb

Type the following command:
# fdisk /dev/sdb
Sample outputs:
The number of cylinders for this disk is set to 8910.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): 
To add a new partition, type n command followed by p command as follows:
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-8910, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-8910, default 8910): +37G
To print the partition table type p command, enter:
Command (m for help): p

Disk /dev/sdb: 73.2 GB, 73295462400 bytes
255 heads, 63 sectors/track, 8910 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          37      297171   83  Linux
Finally, set partition type to "Software Raid" i.e. type 0xfd *(type t command followed by fd code to change partition type to Software RAID):
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fd

Command (m for help): p

Disk /dev/sdb: 73.2 GB, 73295462400 bytes
255 heads, 63 sectors/track, 8910 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          37      297171   fd  Linux raid autodetect
Save the changes and exit to shell prompt by typing w command:
Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Step # 3: Create / Update 37G Partitions For /dev/sda

You need to delete /dev/sda3 (make sure you backup all data) and/or set it to software raid as follows using the fdisk command:
# fdisk /dev/sda
Sample outputs:
The number of cylinders for this disk is set to 8910.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 73.2 GB, 73295462400 bytes
255 heads, 63 sectors/track, 8910 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        3929    31455270   83  Linux
/dev/sda3            3930        8779    38957625   83  Linux
/dev/sda4            8780        8910     1052257+   5  Extended
/dev/sda5            8780        8910     1052226   82  Linux swap / Solaris

Command (m for help): t
Partition number (1-5): 3
Hex code (type L to list codes): fd
Changed system type of partition 3 to fd (Linux raid autodetect)

Command (m for help): p

Disk /dev/sda: 73.2 GB, 73295462400 bytes
255 heads, 63 sectors/track, 8910 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        3929    31455270   83  Linux
/dev/sda3            3930        8779    38957625   fd  Linux raid autodetect
/dev/sda4            8780        8910     1052257+   5  Extended
/dev/sda5            8780        8910     1052226   82  Linux swap / Solaris

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Reload Partition Table Changes

Use the partprobe command to reload the changes without rebooting the box:
# partprobe /dev/sda
OR
# echo 1 > /sys/block/sdb/device/rescan

Step #3: Create RAID 1 Array

To create RAID1 using /dev/sda3 and /dev/sdb1, enter:
# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb1
To see RAID build progress, enter:
# watch cat /proc/mdstat
Sample outputs:

Fig.01: RAID 1 mirroring
Fig.01: RAID 1 mirroring

Once build completed create a filesystem on the new software raid devices, enter:
# mkfs.ext3 /dev/md0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
4872896 inodes, 9737360 blocks
486868 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
298 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000, 7962624

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Mount RAID1 at /raid1

Type the following commands:
# mkdir /raid1
# mount /dev/md0 /raid1/
# df -H /raid1/

Sample outputs:
Filesystem             Size   Used  Avail Use% Mounted on
/dev/md0                40G   185M    38G   1% /raid1

How Do I Test My RAID 1 Array Speed?

Simply use the dd command as follows:
# cd /raid1/
# dd if=/dev/zero of=output bs=8k count=256k
# rm output

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 6.01068 seconds, 357 MB/s

Update /etc/fstab

Make sure RAID1 get mounted when you reboot the system (note >> append redirection):
# echo '/dev/md0 /raid1 ext3 noatime,rw 0 0' >> /etc/fstab

How Do I Get Detailed Information About RAID 1?

Type the following command:
# mdadm --query --detail /dev/md0
Sample outputs:
/dev/md0:
        Version : 0.90
  Creation Time : Wed May 26 01:58:53 2010
     Raid Level : raid1
     Array Size : 38949440 (37.15 GiB 39.88 GB)
  Used Dev Size : 38949440 (37.15 GiB 39.88 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Wed May 26 02:18:22 2010
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : b6f207e4:7f73484f:53f64bfd:e70b77d8
         Events : 0.2

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       17        1      active sync   /dev/sdb1
REFERENCES
http://www.cyberciti.biz/faq/centos-redhat-rhel-linux-setup-create-raid1/

Thursday, September 2, 2010

HOWTO Replace a failing disk on Linux Software RAID-5

— SkyHi @ Thursday, September 02, 2010

Contents

[hide]

[edit] Signs of impending disk failure

[edit] Stage 1: SMART Pre-failure warnings

According to SMART, one of the drives developed an unreadable sector, and sent me an email: "SMART error (CurrentPendingSector) detected":
The following warning/error was logged by the smartd daemon:
   
   Device: /dev/sdb, 1 Currently unreadable (pending) sectors
To determine the extent of the problem, execute a long selftest:
# smartctl -t long /dev/sdb
Some of the symptoms during the pre-failure period are:
  • "Wait for IO" state (%wa in top) goes though the roof; the disk subsystem is effectively halted while the disk tries to recover from the read-error.
  • The system becomes very sluggish at times.
As always, check that your backups are up-to-date and properly readable.

[edit] Stage 2: mdadm Fail event

After encountering some more read-errors, the RAID monitoring software decided to fail the disk/partition that was causing problems:
A Fail event had been detected on md device /dev/md1.
 
 It could be related to component device /dev/sdb2.
 
 Faithfully yours, etc.
 
 P.S. The /proc/mdstat file currently contains the following:
 
 Personalities : [raid6] [raid5] [raid4] [raid1] 
 md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
      128384 blocks [4/4] [UUUU]
 
 md1 : active raid5 sdd2[3] sdc2[2] sdb2[4](F) sda2[0]
      1464765696 blocks level 5, 256k chunk, algorithm 2 [4/3] [U_UU]
 
 unused devices: 
You can verify this information using mdadm:
[root@hal ~]# mdadm --detail /dev/md1
   /dev/md1:
           Version : 0.90
     Creation Time : Sun Sep  2 18:56:50 2007
        Raid Level : raid5
        Array Size : 1464765696 (1396.91 GiB 1499.92 GB)
     Used Dev Size : 488255232 (465.64 GiB 499.97 GB)
      Raid Devices : 4
     Total Devices : 4
   Preferred Minor : 1
       Persistence : Superblock is persistent
   
       Update Time : Tue Feb  2 12:16:34 2010
             State : clean, degraded
    Active Devices : 3
   Working Devices : 3
    Failed Devices : 1
     Spare Devices : 0
   
            Layout : left-symmetric
        Chunk Size : 256K
   
              UUID : f8a183b6:6748af53:6c1c8c11:87458cf7
            Events : 0.964132
   
       Number   Major   Minor   RaidDevice State
          0       8        2        0      active sync   /dev/sda2
          1       0        0        1      removed
          2       8       34        2      active sync   /dev/sdc2
          3       8       50        3      active sync   /dev/sdd2
   
          4       8       18        -      faulty spare   /dev/sdb2
The RAID array is running in degraded mode - the failed disk needs to be replaced as soon as possible. Again, check your backups!

[edit] Prepare for disk replacement

The faulty disk, /dev/sdb, was partitioned and used in two RAID arrays (/dev/md0 and /dev/md1). We need to mark all occurrences of this disk as faulty before physically replacing the disk!
[root@hal ~]# mdadm --fail /dev/md0 /dev/sdb1
   mdadm: set /dev/sdb1 faulty in /dev/md0
The faulty disk is no longer part of any RAID array; erase all data before sending it in for replacement:
[root@hal ~]# dd if=/dev/zero of=/dev/sdb1
   [root@hal ~]# dd if=/dev/zero of=/dev/sdb2

[edit] Recovering from disk failure

[edit] Partitioning

Replace the broken harddisk with a new one, create the proper partitions and set the bootable flag on partition 1:
[root@hal ~]# fdisk -l /dev/sdb
   
   Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
   255 heads, 63 sectors/track, 121601 cylinders
   Units = cylinders of 16065 * 512 = 8225280 bytes
   
      Device Boot      Start         End      Blocks   Id  System
   /dev/sdb1   *           1          16      128488+  fd  Linux raid autodetect
   /dev/sdb2              17      121601   976631512+  fd  Linux raid autodetect
Note that the replacement disk is 1TB, while the original disk was 500GB. You can safely create a partition that is larger than the original one - in fact, this may be useful when doing a "rolling upgrade" to a set of larger disks.

[edit] Add to RAID arrays

Add the new disks/partitions to the RAID arrays:
[root@hal ~]# mdadm --add /dev/md0 /dev/sdb1
   mdadm: added /dev/sdb1
   
   [root@hal ~]# mdadm --add /dev/md1 /dev/sdb2
   mdadm: added /dev/sdb2
Array reconstruction should now begin automatically:
[root@hal ~]# cat /proc/mdstat 
   Personalities : [raid6] [raid5] [raid4] [raid1] 
   md0 : active raid1 sdb1[1] sda1[0] sdc1[2] sdd1[3]
         128384 blocks [4/4] [UUUU]
         
   md1 : active raid5 sdb2[4] sdd2[3] sdc2[2] sda2[0]
         1464765696 blocks level 5, 256k chunk, algorithm 2 [4/3] [U_UU]
         [>....................]  recovery =  0.0% (84068/488255232) finish=193.4min speed=42034K/sec
         
   unused devices: 

[edit] Check boot-loader

The new disk is bootable, but GRUB is not yet installed:
[root@hal ~]# file -s /dev/sda
   /dev/sda: x86 boot sector; partition 1: ID=0xfd, active, starthead 1, startsector 63, 256977 sectors;
            partition 2: ID=0xfd, starthead 0, startsector 257040, 976511025 sectors, code offset 0x48
   
   [root@hal ~]# file -s /dev/sdb
   /dev/sdb: x86 boot sector; partition 1: ID=0xfd, active, starthead 1, startsector 63, 256977 sectors;
            partition 2: ID=0xfd, starthead 0, startsector 257040, 1953263025 sectors
Install GRUB on the new disk, /dev/sdb (GRUB uses different names for your disks, /dev/sda => hd0, /dev/sdb => hd1 etc.):
[root@hal ~]# grub
   <...snip...>
   grub> root (hd1,0)
   root (hd1,0)
    Filesystem type is ext2fs, partition type 0xfd
   grub> setup (hd1)
   setup (hd1)
    Checking if "/boot/grub/stage1" exists... no
    Checking if "/grub/stage1" exists... yes
    Checking if "/grub/stage2" exists... yes
    Checking if "/grub/e2fs_stage1_5" exists... yes
    Running "embed /grub/e2fs_stage1_5 (hd1)"...  15 sectors are embedded.
   succeeded
    Running "install /grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/grub/stage2 /grub/grub.conf"... succeeded
   Done.
   grub> quit
   quit
Verify the result:
[root@hal ~]# file -s /dev/sdb
   /dev/sdb: x86 boot sector; partition 1: ID=0xfd, active, starthead 1, startsector 63, 256977 sectors;
            partition 2: ID=0xfd, starthead 0, startsector 257040, 1953263025 sectors, code offset 0x48

[edit] Wait for reconstruction to complete

During array reconstruction, performance may suffer. Check RAID status for an estimated time of completion:
[root@hal ~]# cat /proc/mdstat 
   Personalities : [raid6] [raid5] [raid4] [raid1] 
   md0 : active raid1 sdb1[1] sda1[0] sdc1[2] sdd1[3]
         128384 blocks [4/4] [UUUU]
         
   md1 : active raid5 sdb2[4] sdd2[3] sdc2[2] sda2[0]
         1464765696 blocks level 5, 256k chunk, algorithm 2 [4/3] [U_UU]
         [===>.................]  recovery = 18.5% (90480896/488255232) finish=147.6min speed=44912K/sec
         
   unused devices: 

[edit] Navigation

Thursday, August 26, 2010

Learn Linux, 101: Maintain the integrity of filesystems

— SkyHi @ Thursday, August 26, 2010
Summary:  Learn how to check the integrity of your Linux® filesystems, monitor free space, and fix simple problems. Use the material in this article to study for the Linux Professional Institute (LPI) 101 exam for Linux system administrator certification—or just to check your filesystems and keep them in good working order, especially after a system crash or power loss.
Overview
In this article, learn to:
  • Verify the integrity of filesystems
  • Monitor free space and inodes
  • Repair simple filesystem problems
This article covers standard and journaling (also called journaling) filesystems with an emphasis is on ext2 (standard filesystem) and ext3 (journaling filesystem), but tools for other filesystems are mentioned too. Most of this material applies to both 2.4 and 2.6 kernels. Most examples in this article use Fedora 12, with a 2.6.32 kernel. Your results on other systems may differ.
This article helps you prepare for Objective 104.2 in Topic 104 of the Linux Professional Institute Certification level 1 (LPIC-1) exams. The objective has a weight of 2.
Prerequisites
To get the most from the articles in this series, you should have a basic knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. Sometimes different versions of a program will format output differently, so your results may not always look exactly like the listings and figures shown here.
You should also be familiar with the material in our article "Learn Linux 101: Create partitions and filesystems."

Checking filesystems

Connect with Ian

Ian is one of our most popular and prolific authors. Browse all of Ian's articles on developerWorks. Check out Ian's profile and connect with him, other authors, and fellow readers in My developerWorks.
In cases when your system crashes or loses power, Linux may not be able to cleanly unmount your filesystems. Thus, your filesystems may be left in an inconsistent state, with some changes completed and some not. Operating with a damaged filesystem is not a good idea as you are likely to further compound any existing errors.
The main tool for checking filesystems is fsck, which, like mkfs, is really a front end to filesystem-checking routines for the various filesystem types. Some of the underlying check routines are shown in Listing 1.

Listing 1. Some of the fsck programs
[ian@echidna ~]$ ls /sbin/*fsck*
/sbin/btrfsck  /sbin/fsck         /sbin/fsck.ext3     /sbin/fsck.msdos
/sbin/dosfsck  /sbin/fsck.cramfs  /sbin/fsck.ext4     /sbin/fsck.vfat
/sbin/e2fsck   /sbin/fsck.ext2    /sbin/fsck.ext4dev  /sbin/fsck.xfs

You may be surprised to learn that several of these files are hard links to just one file as shown in Listing 2. Remember that these programs may be used so early in the boot process that the filesystem may not be mounted and symbolic link support may not yet be available. See our article Learn Linux, 101: Create and change hard and symbolic links for more information about hard and symbolic links.

Listing 2. One fsck program with many faces
[ian@echidna ~]$ find /sbin -samefile /sbin/e2fsck
/sbin/fsck.ext4dev
/sbin/e2fsck
/sbin/fsck.ext3
/sbin/fsck.ext4
/sbin/fsck.ext2

The system boot process use fsck with the -A option to check the root filesystem and any other filesystems that are specified for checking in the /etc/fstab control file. If the filesystem was not cleanly unmounted, a consistency check is performed and repairs are made, if they can be done safely. This is controlled by the pass (or passno) field (the sixth field) of the /etc/fstab entry. Filesystems with pass set to zero are not checked at boot time. The root filesystem has a pass value of 1 and is checked first. Other filesystems will usually have a pass value of 2 (or higher), indicating the order in which they should be checked.
Multiple fsck operations can run in parallel if the system determines it is advantageous, so different filesystems are allowed to have the same pass value, as is the case for the /grubfile and //mnt/ext3test filesystems shown in Listing 3. Note that fsck will avoid running multiple filesystem checks on the same physical disk. To learn more about the layout of /etc/fstab, check the man pages for fstab.

Listing 3. Boot checking of filesystems with /etc/fstab entries
filesystem                           mount point  type   options    dump pass
UUID=a18492c0-7ee2-4339-9010-3a15ec0079bb /              ext3    defaults        1   1
UUID=488edd62-6614-4127-812d-cbf58eca85e9 /grubfile      ext3    defaults        1   2
UUID=2d4f10a6-be57-4e1d-92ef-424355bd4b39 swap           swap    defaults        0   0
UUID=ba38c08d-a9e7-46b2-8890-0acda004c510 swap           swap    defaults        0   0
LABEL=EXT3TEST                            /mnt/ext3test  ext3    defaults        0   2
/dev/sda8                                 /mnt/xfstest   xfs     defaults        0   0
LABEL=DOS                                 /dos           vfat    defaults        0   0
tmpfs                   /dev/shm                         tmpfs   defaults        0   0
devpts                  /dev/pts                         devpts  gid=5,mode=620  0   0
sysfs                   /sys                             sysfs   defaults        0   0
proc                    /proc                            proc    defaults        0   0

Some journaling filesystems, such as ReiserFS and XFS, might have a pass value of 0 because the journaling code, rather than fsck, does the filesystem consistency check and repair. On the other hand, some filesystems, such as /proc, are built at initialization time and therefore do need to be checked.
You can check filesystems after the system is booted. You will need root authority, and the filesystem you want to check should be unmounted first. Listing 4 shows how to check two of our filesystems, using the device name, label, or UUID. You can use the blkid command to find the device given a label or UUID, and the label and UUID, given the device.

Listing 4. Using fsck to check filesystems
[root@echidna ~]# # find the device for LABEL=EXT3TEST
[root@echidna ~]# blkid -L EXT3TEST
/dev/sda7
[root@echidna ~]# # Find label and UUID for /dev/sda7
[root@echidna ~]# blkid /dev/sda7
/dev/sda7: LABEL="EXT3TEST" UUID="7803f979-ffde-4e7f-891c-b633eff981f0" SEC_TYPE="ext2" 
 TYPE="ext3" 
[root@echidna ~]# # Check /dev/sda7
[root@echidna ~]# fsck /dev/sda7
fsck from util-linux-ng 2.16.2
e2fsck 1.41.9 (22-Aug-2009)
EXT3TEST: clean, 11/7159808 files, 497418/28637862 blocks
[root@echidna ~]# # Check it by label using fsck.ext3
[root@echidna ~]# fsck.ext3 LABEL=EXT3TEST
e2fsck 1.41.9 (22-Aug-2009)
EXT3TEST: clean, 11/7159808 files, 497418/28637862 blocks
[root@echidna ~]# # Check it by UUID using e2fsck
[root@echidna ~]# e2fsck UUID=7803f979-ffde-4e7f-891c-b633eff981f0
e2fsck 1.41.9 (22-Aug-2009)
EXT3TEST: clean, 11/7159808 files, 497418/28637862 blocks
[root@echidna ~]# # Finally check the vfat partition
[root@echidna ~]# fsck LABEL=DOS
fsck from util-linux-ng 2.16.2
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
/dev/sda9: 1 files, 1/513064 clusters

If you attempt to check a mounted filesystem, you will usually see a warning similar to the one in Listing 5 where we try to check our root filesystem. Heed the warning and do not do it!

Listing 5. Do not attempt to check a mounted filesystem
[root@echidna ~]# fsck UUID=a18492c0-7ee2-4339-9010-3a15ec0079bb 
fsck from util-linux-ng 2.16.2
e2fsck 1.41.9 (22-Aug-2009)
/dev/sdb9 is mounted.  

WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.

Do you really want to continue (y/n)? no

check aborted.

It is also a good idea to let fsck figure out which check to run on a filesystem; running the wrong check can corrupt the filesystem. If you want to see what fsck would do for a given filesystem or set of filesystems, use the -N option as shown in Listing 6.

Listing 6. Finding what fsck would do to check /dev/sda7, /dev/sda8, and /dev/sda9
[root@echidna ~]# fsck -N /dev/sda7 /dev/sda[89]
fsck from util-linux-ng 2.16.2
[/sbin/fsck.ext3 (1) -- /mnt/ext3test] fsck.ext3 /dev/sda7 
[/sbin/fsck.xfs (2) -- /mnt/xfstest] fsck.xfs /dev/sda8 
[/sbin/fsck.vfat (3) -- /dos] fsck.vfat /dev/sda9 

So far, we have checked ext and vfat filesystems. Let's now check the XFS filesystem on /dev/sda8. As you can see in Listing 7, the fsck command simply tells us that we should use the xfs_check command. If there are no errors, then xfs_check does not display any output. There is a -v option for verbose output, but it is much too verbose for a simple check.

Listing 7. Using fsck with XFS
[root@echidna ~]# fsck /dev/sda8
fsck from util-linux-ng 2.16.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).
[root@echidna ~]# xfs_check /dev/sda8


Monitoring free space
On a storage device, a file or directory is contained in a collection of blocks. Information about a file is contained in an inode, which records information such who the owner is, when the file was last accessed, how large it is, whether it is a directory, and who can read from or write to it. The inode number is also known as the file serial number and is unique within a particular filesystem. See our article Learn Linux, 101: File and directory management for more information on files and directories.
Data blocks and inodes each take space on a filesystem, so you need to monitor the space usage to ensure that your filesystems have space for growth.
The df command
The df command displays information about mounted filesystems. If you add the -T option, the filesystem type is included in the display; otherwise, it is not. The output from df for the Fedora 12 system that we used above is shown in Listing 8.

Listing 8. Displaying filesystem usage
[ian@echidna ~]$ df -T
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/sdb9     ext3    45358500  24670140  18384240  58% /
tmpfs        tmpfs     1927044       808   1926236   1% /dev/shm
/dev/sda2     ext3      772976     17760    716260   3% /grubfile
/dev/sda8      xfs    41933232      4272  41928960   1% /mnt/xfstest
/dev/sda7     ext3   112754024    192248 106834204   1% /mnt/ext3test
/dev/sda9     vfat     2052256         4   2052252   1% /dos

Notice that the output includes the total number of blocks as well as the number used and free. Also notice the filesystem, such as /dev/sbd9, and its mount point: / /dev/sdb9. The tmpfs entry is for a virtual memory filesystem. These exist only in RAM or swap space and are created when mounted without need for a mkfs command. You can read more about tmpfs in "Common threads: Advanced filesystem implementor's guide, Part 3".
For specific information on inode usage, use the -i option on the df command. You can exclude certain filesystem types using the -x option, or restrict information to just certain filesystem types using the -t option. Use these multiple times if necessary. See the examples in Listing 9.

Listing 9. Displaying inode usage
[ian@echidna ~]$ df -i -x tmpfs
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb9            2883584  308920 2574664   11% /
/dev/sda2              48768      41   48727    1% /grubfile
/dev/sda8            20976832       3 20976829    1% /mnt/xfstest
/dev/sda7            7159808      11 7159797    1% /mnt/ext3test
/dev/sda9                  0       0       0    -  /dos
[ian@echidna ~]$ df -iT -t vfat -t ext3
Filesystem    Type    Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb9     ext3   2883584  308920 2574664   11% /
/dev/sda2     ext3     48768      41   48727    1% /grubfile
/dev/sda7     ext3   7159808      11 7159797    1% /mnt/ext3test
/dev/sda9     vfat         0       0       0    -  /dos

You may not be surprised to see that the FAT32 filesystem does not have inodes. If you had a ReiserFS filesystem, its information would also show no inodes. ReiserFS keeps metadata for files and directories in stat items. And since ReiserFS uses a balanced tree structure, there is no predetermined number of inodes as there are, for example, in ext2, ext3, or xfs filesystems.
There are several other options you may use with df to limit the display to local filesystems or control the format of output. For example, use the -H option to display human readable sizes, such as 1K for 1024, or use the -h (or --si) option to get sizes in powers of 10 (1K=1000).
If you aren't sure which filesystem a particular part of your directory tree lives on, you can give the df command a parameter of a directory name or even a filename as shown in Listing 10.

Listing 10. Human readable output for df
[ian@echidna ~]$ df --si ~ian/index.html
Filesystem             Size   Used  Avail Use% Mounted on
/dev/sdb9               47G    26G    19G  58% /

The tune2fs command
The ext family of filesystems also has a utility called tune2fs, which can be used to inspect information about the block count as well as information about whether the filesystem is journaled (ext3 or ext4) or not (ext2). The command can also be used to set many parameters or convert an ext2 filesystem to ext3 by adding a journal. Listing 11 shows the output for a near-empty ext3 filesystem using the -l option to simply display the existing information.

Listing 11. Using tune2fs to display ext4 filesystem information
[root@echidna ~]# tune2fs -l /dev/sda7
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   EXT3TEST
Last mounted on:          
Filesystem UUID:          7803f979-ffde-4e7f-891c-b633eff981f0
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype 
 needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              7159808
Block count:              28637862
Reserved block count:     1431893
Free blocks:              28140444
Free inodes:              7159797
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1017
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Mon Aug  2 15:23:34 2010
Last mount time:          Tue Aug 10 14:17:53 2010
Last write time:          Tue Aug 10 14:17:53 2010
Mount count:              3
Maximum mount count:      30
Last checked:             Mon Aug  2 15:23:34 2010
Check interval:           15552000 (6 months)
Next check after:         Sat Jan 29 14:23:34 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      2438df0d-fa91-4a3a-ba88-c07b2012f86a
Journal backup:           inode blocks

xfs_info
For XFS filesystems you can display the same information that mkfs.xfs displayed when the filesystem was created using the xfs_info as shown in Listing 12. You need to use xfs_info on a mounted filesystem.

Listing 12. Using xfs_info to display XFS filesystem information
[root@echidna ~]# xfs_info /dev/sda8
meta-data=/dev/sda8              isize=256    agcount=4, agsize=2622108 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=10488429, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=5121, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

The du command
The df command gives information about a whole filesystem. Sometimes you might want to know how much space is used by your home directory, or how big a partition to use if you wanted to move /usr to its own filesystem. To answer this kind of question, use the du command.
The du command displays information about the filename (or filenames) given as parameters. If a directory name is given, then du recurses and calculates sizes for every file and subdirectory of the given directory. The result can be a lot of output. Fortunately, you can use the -s option to request just a summary for a directory. If you use du to get information for multiple directories, then add the -c option to get a grand total. You can also control output format with the same set of size options (-h, -H, --si, and so on) that are used for df. Listing 13 shows two views of the home directory of a newly created user who has logged in once and created an index.html file.

Listing 13. Using du
[testuser1@echidna ~]$ du -hc *
4.0K Desktop
4.0K Documents
4.0K Downloads
16K index.html
4.0K Music
4.0K Pictures
4.0K Public
4.0K Templates
4.0K Videos
48K total
[testuser1@echidna ~]$ du -hs .
1.1M .

The reason for the difference between the 48K total from du -c * and the 1.1M summary from du -s is that the latter includes the entries starting with a dot, such as .bashrc, while the former does not.
One other thing to note about du is that you must be able to read the directories that you are running it against.
So now, let's use du to display the total space used by the /usr tree and each of its first-level subdirectories. The result is shown in Listing 14. Use root authority to make sure you have appropriate access permissions.

Listing 14. Using du on /usr
[root@echidna ~]# du -shc /usr/*
394M /usr/bin
4.0K /usr/etc
4.0K /usr/games
156M /usr/include
628K /usr/kerberos
310M /usr/lib
1.7G /usr/lib64
110M /usr/libexec
136K /usr/local
30M /usr/sbin
2.9G /usr/share
135M /usr/src
0 /usr/tmp
5.7G total


Repairing filesystems
Occasionally, very occasionally we hope, the worst will happen and you will need to repair a filesystem because of a crash or other failure to unmount cleanly. The fsck command that you saw above can repair filesystems as well as check them. Usually the automatic boot-time check will fix the problems and you can proceed.
If the automatic boot-time check of filesystems is unable to restore consistency, you are usually dumped into a single user shell with some instructions to run fsck manually. For an ext2 filesystem, which is not journaled, you may be presented with a series of requests asking you to confirm proposed actions to fix particular blocks on the filesystem. You should generally allow fsck to attempt to fix problems, by responding y (for yes). When the system reboots, check for any missing data or files.
If you suspect corruption, or want to run a check manually, most of the checking programs require the filesystem to be unmounted, or at least mounted read-only. Because you can't unmount the root filesystem on a running system, the best you can do is drop to single user mode (using telinit 1) and then remount the root filesystem read-only, at which time you should be able to perform a consistency check. A better way to check a filesystem is to boot a recovery system, such as a live CD or a USB memory key, and perform the check of your unmounted filesystems from that.
If fsck cannot fix the problem, you do have some other tools available, although you will generally need advanced knowledge of the filesystem layout to successfully fix it.
Why journal?
An fsck scan of an ext2 disk can take quite a while to complete, because the internal data structure (or metadata) of the filesystem must be scanned completely. As filesystems get larger and larger, this takes longer and longer, even though disks also keep getting faster, so a full check may take one or more hours.
This problem was the impetus for journaled, or journaling, filesystems. Journaled filesystems keep a log of recent changes to the filesystem metadata. After a crash, the filesystem driver inspects the log in order to determine which recently changed parts of the filesystem may possibly have errors. With this design change, checking a journaled filesystem for consistency typically takes just a matter of seconds, regardless of filesystem size. Furthermore, the filesystem driver will usually check the filesystem on mounting, so an external fsck check is generally not required. In fact, for the xfs filesystem, fsck does nothing!
If you do run a manual check of a filesystem, check the man pages for the appropriate fsck command (fsck.ext3, e2fsck , reiserfsck, and so on) to determine the appropriate parameters. The -p option, when used with ext2, ext3, or ext4 filesystems will cause fsck to automatically fix all problems that can be safely fixed. This is, in fact, what happens at boot time.
We'll illustrate the use of e2fsck and xfs_check by first running e2fsck on an empty XFS filesystem and then using xfs_check to fix it. Remember we suggested that you use the fsck front end to be sure you are using the right checker, and we warned you that failure to do so may result in filesystem corruption.
In Listing 15, we start running e2fsck against /dev/sda8, which contains an XFS filesystem. After a few interactions we use ctrl-Break to break out, but it is too late. Warning: Do NOT do this unless you are willing to destroy your filesystem.

Listing 15. Deliberately running e2fsck manually on an XFS filesystem
[root@echidna ~]# e2fsck /dev/sda8
e2fsck 1.41.9 (22-Aug-2009)
/dev/sda8 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (31223, counted=31224).
Fix? ctrl-Break

/dev/sda8: e2fsck canceled.

/dev/sda8: ***** FILE SYSTEM WAS MODIFIED *****

Even if you broke out at the first prompt, your XFS filesystem would still have been corrupted. Repeat after me. Do NOT do this unless you are willing to destroy your filesystem.
Now let's use xfs_check to repair the XFS filesystem. The xfs_check command is quite verbose, but it has a -s option which reports only serious errors. The output is shown in Listing 16.

Listing 16. Repairing the XFS filesystem using xfs_check
[root@echidna ~]# xfs_check -s /dev/sda8
cache_node_purge: refcount was 1, not zero (node=0x1cf3ee0)
xfs_check: cannot read root inode (117)
cache_node_purge: refcount was 1, not zero (node=0x1cf7400)
xfs_check: cannot read realtime bitmap inode (117)
bad magic # 0x1040000 in btbno block 0/1
bad magic # 0x4000 in btcnt block 0/2
bad magic # 0x58465342 in inobt block 0/0

You can also use xfs_repair to repair an XFS filesystem. Like xfs_check, it is quite verbose, and it does not have an -s option. If you'd like just to see what needs repair without actually repairing it, use xfs_repair -n.
Superblocks
You may be wondering how all these checking and repairing tools know where to start. Linux and UNIX filesystems usually have a superblock, which describes the filesystem metadata, or data describing the filesystem itself. This is usually stored at a known location, frequently at or near the beginning of the filesystem, and replicated at other well-known locations. You can use the -n option of mke2fs to display the superblock locations for an existing filesystem. If you specified parameters such as the bytes per inode ratio, you should invoke mke2fs with the same parameters when you use the -n option. Listing 17 shows the location of the superblocks on /dev/sda7.

Listing 17. Finding superblock locations
[root@echidna ~]# mke2fs -n /dev/sda7
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
7159808 inodes, 28637862 blocks
1431893 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
874 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
 4096000, 7962624, 11239424, 20480000, 23887872


Advanced tools
There are several more advanced tools that you can use to examine or repair a filesystem. Check the man pages for the correct usage and the Linux Documentation Project (see Resources) for how-to information. Almost all of these commands require a filesystem to be unmounted, although some functions can be used on filesystems that are mounted read-only. A few of the commands are described below.
You should always back up your filesystem before attempting any repairs.
Tools for ext2 and ext3 filesystems
tune2fs
Adjusts parameters on ext2 and ext3 filesystems. Use this to add a journal to an ext2 system, making it an ext3 system, as well as display or set the maximum number of mounts before a check is forced. You can also assign a label and set or disable various optional features.
dumpe2fs
Prints the super block and block group descriptor information for an ext2 or ext3 filesystem.
debugfs
Is an interactive file system debugger. Use it to examine or change the state of an ext2 or ext3file system.
Tools for Reiserfs filesystems
reiserfstune
Displays and adjusts parameters on ReiserFS filesystems.
debugreiserfs
Performs similar functions to dumpe2fs and debugfs for ReiserFS filesystems.
Tools for XFS filesystems
xfs_info
Displays XFS filesystem information.
xfs_growfs
Expands an XFS filesystem (assuming another partition is available).
xfs_admin
Changes the parameters of an XFS filesystem.
xfs_repair
Repairs an XFS filesystem when the mount checks are not sufficient to repair the system.
xfs_db
Examines or debugs an XFS filesystem.
We will wrap up our tools review with an illustration of the debugfs command, which allows you to explore the inner workings of an ext family filesystem. By default, it opens the filesystem in read-only mode. It does have many commands that allow you to attempt undeletion of files or directories, as well as other operations that require write access, so you will specifically have to enable write access with the -w option. Use it with extreme care. Listing 18 shows how to open the root filesystem on my system; navigate to my home directory; display information, including the inode number, about a file called index.html; and finally, map that inode number back to the pathname of the file.

Listing 18. Using debugfs
[root@echidna ~]# debugfs /dev/sdb9
debugfs 1.41.9 (22-Aug-2009)
debugfs:  cd home/ian
debugfs:  pwd
[pwd]   INODE: 165127  PATH: /home/ian
[root]  INODE:      2  PATH: /
debugfs:  stat index.html
Inode: 164815   Type: regular    Mode:  0644   Flags: 0x0
Generation: 2621469650    Version: 0x00000000
User:  1000   Group:  1000   Size: 14713
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 32
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x4bf1a3e9 -- Mon May 17 16:15:37 2010
atime: 0x4c619cf0 -- Tue Aug 10 14:39:44 2010
mtime: 0x4bf1a3e9 -- Mon May 17 16:15:37 2010
Size of extra inode fields: 4
Extended attributes stored in inode body: 
  selinux = "unconfined_u:object_r:user_home_t:s0\000" (37)
BLOCKS:
(0-2):675945-675947, (3):1314836
TOTAL: 4

debugfs:  ncheck 164815
Inode Pathname
164815 /home/ian/index.html
debugfs:  q


Conclusion
We've covered many tools you can use for checking, modifying, and repairing your filesystems. Remember to always use extreme care when using the tools discussed in this article or any other tools. Data loss may be only a keystroke away.

Resources
Learn
Get products and technologies
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
Discuss