Pvfs2 failover policy-What Should PVFS do if a hard disk breaks down? Will data be lost?

Unfortunately, when a hard disk in a PVFS cluster breaks down, all data will be lost. PVFS recommends that each node use two hard disks for hardware RAID 1, which can be avoided. At the software level, PVFS does not provide raid-related functions. Here is a reply from the PVFS developer, who clearly wrote why PVFS does not use raid at the software level:

On Sun, Jun 04,200 6 at 10:18:22 + 0800, Eric Zhang wrote:
> PVFS runs smoothly and everything is OK. But I want to know what
> Will happen if any disk damaged, I mean, if one of these disks
> Failed, all data will lose? How pvfs2 deals with this situation?

Pvfs2 deals with this situation the same way a raid-0 array wowould deal
With it: there wocould be a loss of data, and you 'd have to restore
From backups. The common solution is to deploy RAID 1 on each pvfs2
Storage node. Then pvfs2 can sustain one disk failure per storage
Node.

> Have read the "pvfs-ha.pdf" but this kind of solution based on my
> Cluster nodes have redundance disks that I don't have. Does PVFS
> Support redundance storage policy? Just like RAID 1, when data
> Arrives, we write it to two nodes and at the same time, we write
> Another copy of data to the other two nodes. Thanks, any
> Suggestions will be appreciated.

If you don't want to pay for additional hardware and you don't want
Pay for enough storage to back up pvfs2, then you'll have to treat
Pvfs2 as it was intended: As a fast scratch space for applications.
Commonly, data is staged onto pvfs2 before running an IO-intensive
Application and shipped off of to storage which is presumably
Backed-up.

Software-based redundancy is a lot harder to solve at the file-System
Layer than it is at the device layer. Specifically, it's a real
Challenge to in effect write two copies of data without cutting
Overall Write Performance in half. Several research efforts are
Ongoing to deliver software redundancy with high performance,
These efforts are still in early stages.

I hope this explanation is clear. There is definitely a lot of demand
For software-based reduncancy, and we're working on it.