Obviously, Hadoop's holistic set of DataNode worker services along with the NameNode master processes, especially when using HA NN configuration, provide a robust platform for HDFS to survive a failure to a worker node and for the file system to keep on keeping on. Those worker node failures can take a variety of forms (power supply out, NIC problems, controller is fried, etc) and in general it makes sense to simply build a model where you repair or replace the worker node to restore full level of service to the cluster.
As described in hadoop worker node configuration recommendations (1-2-10), many cluster's worker nodes are being provisioned with 8-12 drives which are identified as list of directories in the dfs.datanode.data.dir property of hdfs-site.xml. This many disks introduces a class of failure that is likely to happen somewhat more frequently than general machine failure. That is hard disk failure. Consider a Hadoop cluster with 200 worker nodes each of which have 12 drives devoted to the DataNode and to provide storage to HDFS. That yields 2400 spinning disks just waiting for something bad to happen. Without going into an elaborate discussion on Mean Time Between Failures, or even Seagate's preferred AFR, it is easy enough to imagine one of these hard drives failing per week.
With the default settings of a straightforward Hadoop installation, DataNode processes are configured to stop running once they detect any failures in any of their configured disks. This can be verified by the following stanza in hdfs-site.xml.
<property>
<name<dfs.datanode.failed.volumes.tolerated</name>
<value>0</value>
</property>
For those using Ambari, you can find the following UI snippet at Services > HDFS > Configs.
