※ 引述《in2 (敬請期待 :P)》之銘言： : ※ 引述《reader (讀者)》之銘言： : : 在 PTT 兩岸板，因為大量的爭議性轉信文章，而導致板務 : : 再怎麼努力刪文，每天都會留下數百篇 "(本文已被刪除)" : : 而沒有辦法解決閱讀不便的問題。 : : 有時能趁著凌晨人少時清掉 "(本文已被刪除)"，但終歸是 : : 留下了一整天，意義不大。 : : 希望能不要留下 "(本文已被刪除)", 這樣真的很佔板面。 : : 我不知道問題在哪裡，推文、修文的寫入應該可以用 file : : name 而不需要動到 board index, 但現在卻會有這個現象 : : 導致黑洞。 : 我知道這樣子很佔板面, 可是這樣子做有幾個好處: : 1. : 因為目前 .DIR 是 linear 存的 : (即第一篇放在 0*sizeof(fileheader_t) , 第二篇放在 1*sizeof(fileheader_t)) : 於是要清掉中間其中一篇, 是會導致大量的資料搬動的, : 尤其如果又在尖鋒時段, 系統 loading很高的時候再加上那個板很大的時候, : 這樣做一點都不是好主意. 但是絕大多數時候，都是刪除最近的文章，搬移動作對於系統的 負擔，並不太大。例如兩岸板大多數時候，都是刪除剛轉進來的 文章。 又或者如果是搬移太前面的文章，才使用 (本文已被刪除)。 : 2. : 因為推文、修文會把 fileheader_t 寫到 .DIR 原來的地方, : 如果原來的地方被壓掉的話, 就會爛掉 (所謂黑洞一類的) : 所以使用 (本文已被刪除) 其實可以大量避免黑洞的問題. 我沒有看過 ptt 的原始碼，但早期的 bbs 都有總文章數的設計， 頂多是造成推文推錯或推文數不對，而修文更只是純檔案的操作， 並不需要寫入什麼資訊在 .DIR, 理論上會造成問題的，只有新增 文章才對。可以簡單解釋一下嗎? : : 新增文章跟刪除文章之間，即使不使用 file lock, 或是 : : 更正式一點建立 resource manager, 也可建立簡單的機制 : : 來解決，正規一點用 semaphore, 要不然即使只用簡單的 : : shared memory + sleep 也能在多數狀況下沒有問題才對。 : : 略為看過相關討論，似乎爭議點是在 file lock 的上限， : : 在大站很容易達到，但不使用 lock 的方法有很多，不必 : : 總是卡在那裡吧? : 我覺得現在機器的 loading已經夠大了, : 做一些很暴力的事情 (像是 semaphore) 並不是好主意 @@ : 而且我也想不到要怎麼用比較好? : 一個板一個 semaphore? : 每次有人要讀/ 寫就去 lock 那個 semaphore ? : 那 performance會爛掉 :p : 我還是覺得用本文已刪除最好 ;p 新增文章和刪除文章才需要吧。而且也能透過各板的 busy flag 單用兩個 simaphore 達成 mutex 的效果。 其實 256 個 simaphore 才用到一個 IPC key, 可以製造 128 組 mutex, 並不是那麼佔用系統資源的事，雖然我沒試過 loading 很大的狀況，但也不曾覺得 simaphore 很暴力很傷效能，又不是 要用 Dijkstra 演算法手動自行製造 mutex. 如果現在的 ptt 已改成 multi-threading (應該是吧), 那麼還 能使用 pthread_mutex_lock 的方式，更節省系統資源，不過沒 試過效能如何就是了。 這都不用大改程式碼，不然我更推薦用 thread/process + pipe 專門處理資料新增和刪除，亦即 resource manager 的做法，就 不會有那麼多奇奇怪怪的資源共享問題了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.222.173.26