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