※ 引述《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