zuzu2008 wrote:
那看起來imdisk這個方式也不適合我，
因為我都是要把完成的模型交付給業主，一個模型含工作檔在300g左右，
至少都有80－100萬個檔案。
你這種需求應該要在NAS上使用SSD。
不必整台NAS換成SSD，先登入NAS把檔案移動到NAS的SSD部分，然後再透過網路抓下來，或者就把USB外接SSD裝在NAS上面，然後進去NAS複製檔案，再交給客戶也行。
nwcs wrote:
NAS有速度瓶頸的改(恕刪)
其實並不然，拿SSD來做L2 cache只有`在多人環境下比較有效果。若是單對單的情況下，SSD cache沒有多大的增益，但廠商並不會告訴你這一點…
zuzu2008 wrote:
我昨晚搞到半夜，確認(恕刪)
不，所謂的拿SSD來做為L2 cache是指，將SSD或是更高速的Nvme"附加"為硬碟或陣列的讀寫緩衝，它跟系統拿未用的記憶體來做cache是一樣的，只是速度比不上記憶體，但量大管飽，所以稱為"L2" cache。以ZFS系統來說，這技術稱之為L2 ARC。其他的系統應該有類似的功能，但確切的名稱我就不清楚了。
現行的NAS廠商都會大吹特吹這個功能，中階以上的機器，附加了Nvme，速度似乎就能跑上天一般，但真的是這樣嗎？為什麼我說這功能在單一環境下沒多大作用…
1. 現在區網多為1G，理論傳輸值為125 MB/s，而磁碟I/O都足以應付網路傳輸，瓶頸在網路頻寬而非磁碟I/O，Nvme速度再快又有鳥用。嗯，也不能這麼講，Nvme做為L2 cache在NAS"本機"的磁碟I/O上，還是有很大的作用的，只不過NAS最常用的還是在網路的傳輸上，嗯，這……。另外快取的讀寫(主要是寫入)對網路傳輸還是有幫助的，只是在1G網路上不夠明顯。在10G網路上，磁碟I/O低於網路傳輸，這時記憶體快取發揮作用，但記憶體容量畢竟有限，量大管飽的Nvme做為L2 cache才有較明顯的效益。只是目前架構10G網路，對一般user來說還是有一定難度，so...
2. 像我之前說的，快取對寫入較有幫助在於，對PC端來說，它資料只要丟到快取就算傳輸完成，不必去管後續資料寫入硬碟的動作。讀取時，資料載入快取，對第一筆的讀取並無效益，它只對後續讀取同一筆資料有增益。一般單對單環境下，或者擴大一些，一般家庭環境使用下，反複讀取同筆資料的機率有多大？因此，快取的讀取在多對單的環境下，像辦公室，才有比較明顯的效益。快取也不是愈大愈好，對讀取來說，容量愈大，可容納快取的資料愈多，但相對的，存取快取裏資料的延遲也會變大，且會佔用一部份的記憶體做快取索引。以ZFS來說，記憶體小於32G的環境不適合開啟L2 ARC。
我之前在學習ZFS時也對L2 ARC感到驚訝，怎麼有這麼棒的技術。實際上在學習摸索中才發現，L2 ARC對一般使用者來說沒多大的效果，它比較適合用在企業、多人的環境下。不過這一些，NAS的廠商都不會告訴你，只會讓你覺得加了Nvme做快取，機器就能飛上天一般的快，實際上…
樓主的需求是大量小檔案的傳輸，這沒有較好的方法，磁碟的I/O、網路傳輸的建立，事實限制就在那裏。比較好的改善方案就是打包後再傳輸，不必壓縮，直接打包即可；或者使用iSCSI，附掛NAS為本機磁碟，iSCSI在處理小檔案上效能較高。根據我很久以前的測試，寫入約增加１倍，讀取約增加3成。不過參考就好，畢竟使用的硬體、系統不同…
以前的 MLC顆粒，連續寫入掉速沒那麼明顯。但那個很難買了，容量又超小。
如果放 NAS 目的是要讓客戶透過網路下載，覺的還是壓縮打包吧。
那種巨量小檔、模型檔，壓縮起來，壓縮率應該很可觀，說不定少一半容量，下載也省時，畢竟外面連上去網速可不是 1G bps的。下載未壓縮330GB，和下載壓縮後比方200GB，省時太多了。
最好是用分割壓縮，每檔1GB左右。免得下載過程出錯，整個白下要重新來。如果每個分割檔1GB，下壞了只要重新下那個1GB檔即可。
壓縮時，
【來源】【輸出位置】不要同一顆磁碟
避免一邊讀取，一邊寫入，狂操硬碟會很慢，且容易壞軌
比方，那個 330GB 的資料在 D：
壓縮時，輸出到到 E: 什麼的別顆磁碟去
壓縮等級：
- 最快速（快）
- 一般
- 超濃縮（慢）
則是看 CPU 速度而定。CPU如果很強，可以選一般的或超濃縮的，進一步縮小容量。或者要省時選最快速就好，有壓總比沒壓強。
fedora wrote:
如果放 NAS 目的是要讓客戶透過網路下載，覺的還是壓縮打包吧。
fedora wrote:
樓主的需求是大量小檔案的傳輸，這沒有較好的方法，磁碟的I/O、網路傳輸的建立，事實限制就在那裏。比較好的改善方案就是打包後再傳輸，不必壓縮，直接打包即可；或者使用iSCSI，附掛NAS為本機磁碟，
對於NAS內放照片供瀏覽，影片供寬賞的用途，如何使用打包/壓縮，以加速過程，個人有些疑惑：
如果打包/壓縮，是在性能較好的PC端進行，再傳給NAS，那無懸念。
但NAS最終還是需要把打包/壓縮檔給解壓縮，供照片管理程式或網站使用，畢竟你要看到的是一張張照片、影片，而不是打包/壓縮檔案。
個人疑惑：
1.以上面這個過程來說，如果是先在PC端打包/壓縮，傳給NAS，然後在NAS內進行解壓縮，先不談PC、NAS都要放1.5-2倍的硬碟空間，以NAS弱弱的硬體，這樣速度會比直接由PC端直接傳一堆照片小檔案要好嗎？
2.我如果直接丟，找1個不在或睡眠時間讓他跑就可以了，但打包/壓縮再解壓縮，等於人就被綁在現場了，或是要分成打包/壓縮跟解壓縮2個不同時間點來進行。這似乎有違USER使用習慣，因為傳進NAS只是第一步，真正費工的是，後續的分類跟標記，你分成2個時間點進行，不知是否會對USER造成困擾？
我的客戶多是只會單純使用NAS，不會打包/壓縮，這對他們來說，是脫褲子放屁，但如果能節省大把時間，其實或許能勸他們學一下。
>>可以只打包，不壓縮，其實很快，不耗什麼資源
2.我如果直接丟，找1個不在或睡眠時間讓他跑就可以了，但打包/壓縮再解壓縮，等於人就被綁在現場了，或是要分成打包/壓縮跟解壓縮2個不同時間點來進行。這似乎有違USER使用習慣，因為傳進NAS只是第一步，真正費工的是，後續的分類跟標記，你分成2個時間點進行，不知是否會對USER造成困擾？
>>若要自動化，或許可以這樣做
PC端，寫一個批次檔，將檔案打包並傳送至NAS端特定資料夾
NAS端，寫一個shell script，排程，程式執行時若發現特定資料夾內有檔案則解壓縮
其實之前講的打包是指在區網上的應用，把NAS單純當一個儲存裝置。例如，我習慣會把整理好的照片打包成zip檔，現在的秀圖軟體大部份都有支援直接讀取zip檔，我要檢視照片不用先把照片解壓縮，透過區網存取跟在本機沒什麼不同。但你若要開放給外部的人存取，這種方式就不適用了。
內文搜尋
從 APP 打開
X