亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: 為什么單目錄下子文件過多會影響性能? [打印本頁]

作者: 瑪莉隔壁 時間: 2009-02-25 20:36
標題: 為什么單目錄下子文件過多會影響性能?
為什么單目錄下子文件過多會影響性能?如1個目錄下有10000個子文件，那么讀取某個文件的速度將會明顯慢下來？這和文件索引有關(guān)嗎？索引中如何組織這些節(jié)點？謝謝大家?guī)兔?hr noshade size="2" width="100%" color="#808080"> 作者: fhzxt 時間: 2009-02-25 21:09
大致說一下，硬盤的基本單位是塊，塊有獨立地址，文件的地址（類似于指針）由一個索引塊組織，因為一個塊的大小是有限的，所以只能存儲一定數(shù)量的文件地址，當一個目錄的文件數(shù)超過這個數(shù)量時，就需要將索引塊也索引起來，就是索引的索引，即為2重索引，如果還不夠就要3級索引，這自然會影響速度。一些名詞可能用錯，大致意思就是這樣。
ps：據(jù)說現(xiàn)在有些文件系統(tǒng)（比如殺人犯的那個）使用btree作為索引結(jié)構(gòu)，可以提高小文件的查找速度

作者: 瑪莉隔壁 時間: 2009-02-25 21:19
b+tree的結(jié)構(gòu)應(yīng)該不用考慮單個目錄文件過多問題吧？

作者: fhzxt 時間: 2009-02-25 21:27
按Btree的結(jié)構(gòu)就查找看影響很小，如果排序合理的話，可以減少數(shù)量級的查找量。
具體還是做個實驗比較好，畢竟我們并不知道現(xiàn)在bsd的ufs的確切查找和管理方式。

[ 本帖最后由 fhzxt 于 2009-2-25 21:33 編輯 ]

作者: prolj 時間: 2009-02-25 22:35

原帖由 fhzxt 于 2009-2-25 21:09 發(fā)表
大致說一下，硬盤的基本單位是塊，塊有獨立地址，文件的地址（類似于指針）由一個索引塊組織，因為一個塊的大小是有限的，所以只能存儲一定數(shù)量的文件地址，當一個目錄的文件數(shù)超過這個數(shù)量時，就需要將索引塊也 ...

Reiser 的特點不是 B Tree，而是實現(xiàn)了其變種的 B* Tree ，小文件性能好是不給小文件分配 inode （直接存在 Tree 里面？記不清楚了）

作者: fhzxt 時間: 2009-02-25 22:36
無聊得很，就隨便編了一個能自動創(chuàng)建文件的程序，參數(shù)是：a.out 首起文件名數(shù)量
發(fā)現(xiàn)單一目錄下文件再多（數(shù)10w）也不影響查找，不過似乎對創(chuàng)建和刪除有嚴重的影響，類似于溢出，看記錄：
[zhpalt@freebsd]~> time ./a.out /tmp/a/test 30000
0.074u 1.022s 0:05.66 19.2%    5+178k 0+765io 0pf+0w
[zhpalt@freebsd]~> time ./a.out /tmp/a/test2 30000
0.014u 1.263s 0:05.06 25.0%    5+182k 0+871io 0pf+0w
[zhpalt@freebsd]~> time ./a.out /tmp/a/test3 30000
0.060u 1.277s 0:05.57 23.8%    5+176k 0+879io 0pf+0w
[zhpalt@freebsd]~> time ./a.out /tmp/a/test4 30000
0.036u 1.228s 0:05.95 21.0%    5+182k 2+1109io 0pf+0w
[zhpalt@freebsd]~> time ./a.out /tmp/a/test5 30000
^C0.123u 67.972s 1:10.30 96.8%  5+181k 38+1038io 0pf+0w
（最后一步，實踐太長了，我不得不終止了。）
數(shù)量已經(jīng)超出ls和rm的范圍：
/sbin/ls: Argument list too long.
/bin/rm: Argument list too long.

作者: fhzxt 時間: 2009-02-25 22:38

原帖由 prolj 于 2009-2-25 22:35 發(fā)表

Reiser 的特點不是 B Tree，而是實現(xiàn)了其變種的 B* Tree ，小文件性能好是不給小文件分配 inode （直接存在 Tree 里面？記不清楚了）

恩，是這樣，我沒注意到那個*，我查了下，他的查找用的是平衡樹，存儲是B*Tree

作者: prolj 時間: 2009-02-25 23:04
性能好的原因是小文件直接存儲在 Tree 節(jié)點中？好像還叫什么壓縮。
Reiser4 是更好的選擇。

作者: fhzxt 時間: 2009-02-25 23:26
LZ，突然發(fā)現(xiàn)這種問題似乎沒必要去想，看別人的討論不就完了，請看同一個人在cu和freebsdchina分別和G版及delphij的討論（看的時候，千萬不能細想那些計算啊，因為本身基礎(chǔ)可能是錯的）：
http://72891.cn/viewthread.php?tid=1320304
http://www.freebsdchina.org/forum/topic_43473.html
ps：Reiser及l(fā)inux下多種文件系統(tǒng)對比，參考資料http://www.ibm.com/developerworks/cn/linux/l-jfs/

作者: 瑪莉隔壁 時間: 2009-02-26 08:46
謝謝

作者: 瑪莉隔壁 時間: 2009-02-26 15:29

原帖由 fhzxt 于 2009-2-25 23:26 發(fā)表
LZ，突然發(fā)現(xiàn)這種問題似乎沒必要去想，看別人的討論不就完了，請看同一個人在cu和freebsdchina分別和G版及delphij的討論（看的時候，千萬不能細想那些計算啊，因為本身基礎(chǔ)可能是錯的）：
http://bbs.chinauni ...

看完這些，我又覺得自己渺小了許多

作者: fhzxt 時間: 2009-02-26 15:35
慢慢學習吧

作者: gvim 時間: 2009-02-27 00:44

原帖由 fhzxt 于 2009-2-25 21:27 發(fā)表
按Btree的結(jié)構(gòu)就查找看影響很小，如果排序合理的話，可以減少數(shù)量級的查找量。
具體還是做個實驗比較好，畢竟我們并不知道現(xiàn)在bsd的ufs的確切查找和管理方式。

UFS的inode結(jié)構(gòu)里有幾個字段是記錄間接塊地址的（到底是磁盤LBA還是文件系統(tǒng)的邏輯快號我記憶有些模糊了，依稀記得是LBA），查找的算法可以參看現(xiàn)在市面上絕大多數(shù)Unix設(shè)計或?qū)崿F(xiàn)的教材，大多數(shù)都以UFS的inode設(shè)計做的講解。
管理的話比較麻煩，涉及太多性能優(yōu)化。
不過說個題外話，我個人估計現(xiàn)存的主流文件系統(tǒng)對文件數(shù)據(jù)的管理方式在不久的幾年之內(nèi)會被大量簡化。當固態(tài)硬盤便宜到一定程度的時候(就如同LCD取代CRT顯示器)，現(xiàn)存文件系統(tǒng)優(yōu)化的設(shè)計基礎(chǔ)----盡量減少磁頭的無用移動----就沒有了，訪問硬盤就像訪問內(nèi)存，給個地址然后由電路處理。那時候可能真的會把內(nèi)存文件系統(tǒng)(或內(nèi)存系統(tǒng)管理、或Flash文件系統(tǒng))的一些設(shè)計經(jīng)驗用到磁盤文件系統(tǒng)上來。

PS:過年的時候差點買個帶SSD的本子

作者: fhzxt 時間: 2009-02-27 11:15
恩，主流方向是如此，估計win用戶會很高興的，因為windows的碎片整理可以成為歷史了

不過現(xiàn)在固態(tài)硬盤還是超貴的說

作者: gvim 時間: 2009-02-27 11:20
放心吧，5年前我還不敢奢望用21寸的液晶呢，17寸的都超貴

作者: macafee 時間: 2009-02-27 13:51

原帖由 gvim 于 2009-2-27 11:20 發(fā)表
放心吧，5年前我還不敢奢望用21寸的液晶呢，17寸的都超貴

5年后EIZO的東西依然還是如此昂貴！

歡迎光臨 Chinaunix (http://72891.cn/)