Comme Matt m'a complètement largué dans ses réponses techniques et que j'ai du faire une traduction à l'aveuglette de son interview je me permet de coller ci-dessous l'original. Cela permettra aux gens calés de corriger mes faux-sens et, peut-être, d'expliquer de quoi il retourne aux pauvres peóns que nous sommes.
Q: DragonFlyBSD is less known than Free/Net/OpenBSD. How many developpers/testers are part of the team ?
We have about 12 serious coders and about 50 people total. I'd say we have a few hundred users... not huge numbers. Most new users are attracted by the HAMMER filesystem.
Q: You forked FreeBSD due to technical disagreements. Do you still think the FreeBSD choices were wrong ?
Yes. I believe the DragonFly has been able to achieve better stability over time as it has been improved.
Q: Why the serializing tokens model is better than the fine-grained mutex model ?
There are more model differences then that. The serializing tokens have the two-fold advantage of being (1) deadlock-free because they are automatically unlocked when a thread explicitly blocks and relocked on resume, and (2) allow subsystem calls which do not have to have any knowledge of which tokens might already be held. Because tokens are tracked by the scheduler the scheduler itself can efficiently determine which runnable threads can actually acquire all their locks and run, verses other models.
We use three types of locks. The tokens are primarily used for long-duration list scans such as mountlist scans. Lockmgr locks are used for locks which must be held across blocking conditions. And spinlocks are used for short-duration-only exclusive access.
The other major model difference is that we use per-cpu data localization for numerous subsystems which allowed them to be coded in a straightforward manner without locks.
Q: The technical goals of DragonFlyBSD are very impressive but the most known part is HAMMER. How does it compare to the other modern file systems ?
It compares very well. Directory scans a bit slower than they could be (somewhere inbetween ext and reiser, but not as bad as reiser).
With the recent REDO/fsync enhancements our fsync performance is now extremely good and with the new swapcache support capable of caching 64+ million inodes on a SSD the file lookup performance is extremely good.
File read/write performance is very good.
I'm not in the business of doing specific performance comparisons but I will note that HAMMER has features, such as instant recovery, fine-grained history, and automatic snapshotting. Most other filesystems just don't have these features or do not have them integrated anywhere near as well as they exist in HAMMER.
The fine-grained history impacts performance a little and tends to impact benchmarks more than it does production operation because maintainance occurs on a 24-hour clock instead of instantly.
The snapshotting is incredibly powerful and since it is automatic you can just assume that you have the last 60 days worth of snapshots available (the default retention can be changed of course) and trivially CD into them on the live system if you need to recover something or do a comparison or whatever.
The non-queued streaming mirroring is also incredibly powerful.
Q: Why the others BSD didn't import HAMMMER in their trunks ?
It's up to them whether they want to or not. Generally speaking the buffer cache interactions are difficult to port.
Q: According to you how far is DragonFlyBSD of the mythical SSI clustering goal ?
It's hard to say but I think still at least 2 years away. I said this 2 years ago too. The goal keeps on getting pushed back in favor of improving things we already have working, such as HAMMER.
# Full disclosure
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de DragonFly BSD 2.6 et entretien avec Matt Dillon. Évalué à 10.
Q: DragonFlyBSD is less known than Free/Net/OpenBSD. How many developpers/testers are part of the team ?
We have about 12 serious coders and about 50 people total. I'd say we have a few hundred users... not huge numbers. Most new users are attracted by the HAMMER filesystem.
Q: You forked FreeBSD due to technical disagreements. Do you still think the FreeBSD choices were wrong ?
Yes. I believe the DragonFly has been able to achieve better stability over time as it has been improved.
Q: Why the serializing tokens model is better than the fine-grained mutex model ?
There are more model differences then that. The serializing tokens have the two-fold advantage of being (1) deadlock-free because they are automatically unlocked when a thread explicitly blocks and relocked on resume, and (2) allow subsystem calls which do not have to have any knowledge of which tokens might already be held. Because tokens are tracked by the scheduler the scheduler itself can efficiently determine which runnable threads can actually acquire all their locks and run, verses other models.
We use three types of locks. The tokens are primarily used for long-duration list scans such as mountlist scans. Lockmgr locks are used for locks which must be held across blocking conditions. And spinlocks are used for short-duration-only exclusive access.
The other major model difference is that we use per-cpu data localization for numerous subsystems which allowed them to be coded in a straightforward manner without locks.
Q: The technical goals of DragonFlyBSD are very impressive but the most known part is HAMMER. How does it compare to the other modern file systems ?
It compares very well. Directory scans a bit slower than they could be (somewhere inbetween ext and reiser, but not as bad as reiser).
With the recent REDO/fsync enhancements our fsync performance is now extremely good and with the new swapcache support capable of caching 64+ million inodes on a SSD the file lookup performance is extremely good.
File read/write performance is very good.
I'm not in the business of doing specific performance comparisons but I will note that HAMMER has features, such as instant recovery, fine-grained history, and automatic snapshotting. Most other filesystems just don't have these features or do not have them integrated anywhere near as well as they exist in HAMMER.
The fine-grained history impacts performance a little and tends to impact benchmarks more than it does production operation because maintainance occurs on a 24-hour clock instead of instantly.
The snapshotting is incredibly powerful and since it is automatic you can just assume that you have the last 60 days worth of snapshots available (the default retention can be changed of course) and trivially CD into them on the live system if you need to recover something or do a comparison or whatever.
The non-queued streaming mirroring is also incredibly powerful.
Q: Why the others BSD didn't import HAMMMER in their trunks ?
It's up to them whether they want to or not. Generally speaking the buffer cache interactions are difficult to port.
Q: According to you how far is DragonFlyBSD of the mythical SSI clustering goal ?
It's hard to say but I think still at least 2 years away. I said this 2 years ago too. The goal keeps on getting pushed back in favor of improving things we already have working, such as HAMMER.