Linux數據，做/var黨，還是/opt黨，還是/usr/local黨，還是/home黨呢?

01-29

以前我喜歡放/home, 但這兩年我比較接受/var放運行數據, 現在docker用得比較多，發現很多image還是喜歡用/usr/local來裝軟體，奇葩的jenkins的更是要用/var/jenkins_home來放運行數據，雖然可以-v映射，但在build時我還是經常要寫shell script來找這個目錄的 - -
補充一下提問的原因
寫了一套小型應用，發布到一台雲主機上，需要用到mysql，然後順帶我就rpm裝了，然後過了一段時間我才發現 / 分區的磁碟很小，而 /home 划了非常大，問同事，他說這是客戶對雲主機鏡像的要求，然後又諮詢了一下客戶的dba，他告訴我他們之前其他的mysql都把數據放/opt下(前任留下的規矩)。
其實使用lvm，已經無所謂數據放到那個分區了，我覺得一個 / 分區就夠了。
現在關注自動化運維，不同的安裝策略導致運維方面的不統一我都設法盡量避免。

我自己早先年，接受一些資料庫的安裝文檔的概念，喜歡/opt下安裝應用，然後將data目錄設置到/home。甚至自己的愛機，也是非常潔癖的只在/home下放東西。
這兩年的工作和運維的關係比較多，更喜歡用 rpm/deb 默認的 /var 來放數據或者日誌。

這事情要考慮的東西很多

應用是否對 IO 敏感，要給他的數據獨立的硬碟，和系統的 IO 隔離開。如果這樣的話這個獨立的硬碟肯定不能掛載到 /var 了，因為 /var 下面是有很多操作系統自己的 IO 讀寫的。

現狀如何，每個分區分配了多少大小，調整分區大小和調整目錄，哪個的成本比較小

把數據放在 /var 下面是有風險的，比如有時候某個其他程序出了 bug 刷大量錯誤日誌到 /var/log 十分鐘就把分區填滿了，等發現的時候應用已經因此 crash 了，要考慮這個風險能否承受。如果 /var 下面的 IO 很高這個分區出問題的可能性會高於其他分區，要考慮這個風險能否接受

客戶的習慣如何，強行要求客戶改變習慣（並且付出改變習慣的成本，比如修改大量現有腳本的路徑）是否有必要（可以考慮軟連接之類的折中辦法）

軟體默認配置在哪個分區，有配置文件還是 hardcode，應用能否接受重啟，修改成本有多高

等等

去Google了一下這個問題，其實有一個 FHS (Filesystem Hierarchy Standard) 試圖制定一個文件層次結構標準，不說這個標準是否一定合理，但學習一下還是很好的。

Where in the filesystem should I store shared data?

真要說的話，我是 /home 派。

1. 業務

磁碟分割不會指定大小，直接整塊切成 /

其他路徑的區別一律使用 soft link 做鏈接。

所有業務有關的資料，全部放在 /home/username 底下。

這個 username 就是運維的作業帳戶。

如果有特殊服務，如 mysql , 是肯定會佔用磁碟的，

那我就會獨立掛載一顆硬碟，/mnt

然後把 home 的內容搬過去，做一個軟鏈接連到 /home

再 /home/mysql/data ln -s /var/lib/mysql/data

理由很簡單，省事，默認萬歲。

注意下剛開始，/home/username 一般都沒有 x 許可權。

這個加上就好，修改不是很大，或者把 /etc/skel 模板給修了，

我比較不建議這麽做，因為默認萬歲。

2. 安裝軟體

直接 make install 一般都是安裝到 /usr/local 下

所以這部份我也是默認萬歲，不做任何修改。

主機一多，服務一多，這些額外的路徑配置就變成判斷成本，

也變成安裝原版系統之後必須要配置的東西，

既然這樣，全部按照默認，也有很高一致性，許多說明文件、網路知識資源，

也是以這邊為起點，那有什麽理由必須換呢？

像你提到的，Docker 的 volume 作為一個中間層已經很好地解決了這個問題。比起 /var/data 這樣的約定，volume 更明確地描述了應用存放數據的位置。

即使不用 Docker ，symlink 也能把「應用訪問文件的路徑」和「文件佔用的磁碟分區空間」解耦。

作為運維角色，明明有 volume / symlink 這樣的工具不用，而一定要制定規則讓其它人花時間來節約你自己的工作量，不總是對的。

特意搜了一下這個問題，今天剛發微博吐槽了下：

也不知道線上環境要使用 /opt /data 作為掛... 來自Crzidea