不支持softdep,推荐log,(fstab)
版主: wkx9dragon
-
- 锌 Zn
- 帖子: 493
- 注册时间: 2010-02-02 18:00
不支持softdep,推荐log,(fstab)
自从根新到-current,softdep,就不支持了,不知道log,和softdep,性能差别大吗?有人呢比较过吗?
-
- 锌 Zn
- 帖子: 493
- 注册时间: 2010-02-02 18:00
-
- 锌 Zn
- 帖子: 493
- 注册时间: 2010-02-02 18:00
找到取消softdep,推荐log 的原因了,但是openbsd没有动作很奇怪哦。不过他默认是没有softdep。
[email protected];
Considering these paper/slides presented at BSDCon 2010:
http://www.mckusick.com/publications/suj.pdf
http://www.mckusick.com/publications/suj-slides.pdf
It appears that there now is an option to use a combination of soft
updates and journalling on FreeBSD. Our softdep code was removed in
-current, considering the burden of fixing it when an alternative,
WAPBL became available.
However, this probably means that FreeBSD would also have a less buggy
and MP-safe softdep implementation which might possibly be portable to
NetBSD (although possibly invasive code, as our softdep was), and that
this alternative used with logging might potentially result in less I/O
overhead than WAPBL as well as better metadata referencial integrity.
As I recall, with WAPBL (as with FFS without softdep) it's possible for
extra blocks (potentially garbage) to remain attached to files in the
event of a crash, which is a problem of FFS itself, but which softdep
helped to mitigate.
After I read about this today, I thought I'd share the links, in case
interested parties want to consider trying future alternatives to
FFS+WAPBL or LFS on NetBSD.
Thanks,
--
Matt
[email protected];
Considering these paper/slides presented at BSDCon 2010:
http://www.mckusick.com/publications/suj.pdf
http://www.mckusick.com/publications/suj-slides.pdf
It appears that there now is an option to use a combination of soft
updates and journalling on FreeBSD. Our softdep code was removed in
-current, considering the burden of fixing it when an alternative,
WAPBL became available.
However, this probably means that FreeBSD would also have a less buggy
and MP-safe softdep implementation which might possibly be portable to
NetBSD (although possibly invasive code, as our softdep was), and that
this alternative used with logging might potentially result in less I/O
overhead than WAPBL as well as better metadata referencial integrity.
As I recall, with WAPBL (as with FFS without softdep) it's possible for
extra blocks (potentially garbage) to remain attached to files in the
event of a crash, which is a problem of FFS itself, but which softdep
helped to mitigate.
After I read about this today, I thought I'd share the links, in case
interested parties want to consider trying future alternatives to
FFS+WAPBL or LFS on NetBSD.
Thanks,
--
Matt
在线用户
正浏览此版面之用户: 没有注册用户 和 0 访客