Preface
APP Scenario Description:
When you are unable to plan your storage properly, the storage re-planning (eg, one or several apps that write bigdata for a certain LV-mount point in a post-maintenance job may soon be out of space for your LV mount point, but it's worth noting that Does your other LV mount point have a large storage space? Basically not applied to this LV mount point to write data?) According to the previous description, we know that the problem solution we might be able to choose is
1, change the location of the application's write data (difficult to do?) scenario analysis, adding to the pre-deployment you ins an Oracle initialization setting data to save the directory, and it happens that Oracle's application data is very large? A cloud computing platform software configuration settings deploy VM disk save path?.....)
2, add PV in the VG Center, direct expansion Bigdata The mount point where the data is stored is located on the LV or VG where there is pvfree (this we have already said the specific operation) posts see the following URL
Http://www.cnblogs.com/ruiy/p/4156426.html
3, one of your mount points of the LV space is gone (Bigdata app on this LV mount point write bigdata), and happen to another one or more n mount point of the LV space is very large, and almost no application to write data or write very little data, you can choose reduce This LV storage space to the VG, and then use these reduced out of space to expand to enough LV!
The Linux system uses a number of PV or one partition of a single standalone PV to create the VG, then establishes the LV in the VG, and finally uses LVM to maintain the environment (to dynamically maintain the storage of the OS)
Linux disk space expansion VG (+PV) LV (+ space) LV (reduced disk space)