※ 引述《[email protected] (敬請期待 :P)》之銘言： : 我知道這樣子很佔板面, 可是這樣子做有幾個好處: : 1. : 因為目前 .DIR 是 linear 存的 : (即第一篇放在 0*sizeof(fileheader_t) , 第二篇放在 1*sizeof(fileheader_t)) : 於是要清掉中間其中一篇, 是會導致大量的資料搬動的, : 尤其如果又在尖鋒時段, 系統 loading很高的時候再加上那個板很大的時候, : 這樣做一點都不是好主意. : 2. : 因為推文、修文會把 fileheader_t 寫到 .DIR 原來的地方, : 如果原來的地方被壓掉的話, 就會爛掉 (所謂黑洞一類的) : 所以使用 (本文已被刪除) 其實可以大量避免黑洞的問題. 建議由系統過濾 [空文] 好了. 也就是 i/o 用一個純 append 的 .DIR , 定期才鎖死清洗一次, 而 presentation 則可以用 $pid.DIR.tmp 作為一個緩衝. 即使是大流量, .tmp 的形態或 許不夠穩, 但這也是暫時的 presentation. 對於修改、推文、砍殺等行動, 就必須按 .DIR 的絕對位置下 手. 由於 .tmp 是按 $pid 分配, 也有相對的穩定性, 不太用 擔心互動底下出現移位. : 我覺得現在機器的 loading已經夠大了, : 做一些很暴力的事情 (像是 semaphore) 並不是好主意 @@ : 而且我也想不到要怎麼用比較好? : 一個板一個 semaphore? : 每次有人要讀/ 寫就去 lock 那個 semaphore ? : 那 performance會爛掉 :p : 我還是覺得用本文已刪除最好 ;p 那不妨先交給會寫的人寫了程式, 由其他 loading 未算大的 站作各種測試 (包括實際效能). performance 和 presentation 如何 trade off, 是因不同的 板的價值而異的. 假如僅僅讓某幾個板用 semaphore (雖然這 和全用的分別大極有限) , 影響可以略為減低. --

※ 發信站: 香港地(hkday.net) ◆ From: 61.238.142.110