matthew dillon

A Quick Review of DragonFly BSD 1.4

Topix - Unix  Sat, 09/27/2008 - 04:56

DragonFly BSD 1.4 is the third major release of Matthew Dillon's fork of the FreeBSD operating system, and significant progress has been made towards reaching many of the project's numerous goals.


 

Comparing HAMMER And Tux3

KernelTrap - Kernel news  Thu, 08/07/2008 - 10:25

"The big advantage Hammer has over Tux3 is, it is up and running and released in the Dragonfly distro," began Daniel Phillips, offering a comparison between the two filesystem.

He continued, "the biggest disadvantage is, it runs on BSD, not Linux, and it so heavily implements functionality that is provided by the VFS and block layer in Linux that a port would be far from trivial.


 

DragonFly BSD 2.0

Digg Linux/Unix upcoming  Tue, 07/22/2008 - 16:15

Matthew Dillon announced the availability of DragonFly BSD 2.0: "2.0 is our eighth major DragonFly release. DragonFly's policy is to only commit bug fixes to release branches."


 

BSD Release: DragonFly BSD 2.0

DistroWatch.com: News  Mon, 07/21/2008 - 21:45

Matthew Dillon announced the availability of DragonFly BSD 2.0: "2.0 is our eighth major DragonFly release.

DragonFly's policy is to only commit bug fixes to release branches." Changes in this release include: the HAMMER filesystem featuring crash recovery on-mount (without fsck) and queueless incremental mirroring, numerous kernel changes....


 

HAMMER Performance and Mirroring

KernelTrap - Kernel news  Fri, 06/20/2008 - 10:28

Matthew Dillon continues to make significant progress on his HAMMER clustering filesystem for DragonFly BSD. He labeled the latest release 56c, noting that it, "represents an additional significant improvement in performance, [also including] bug fixes and most of the final media changes." A significant improvement in write performance was obtained by making the filesystem block size automatically increase from 16K to 64K when a file grows to larger than 1 MB.


 

HAMMER's B+Tree Implementation

KernelTrap - Kernel news  Tue, 06/17/2008 - 21:52

"HAMMER makes no modifications to the B-Tree whatsoever on the front-end. When you create, delete, rename, write, etc... when you do those operations HAMMER caches them in a virtualization layer in memory and doesn't make any modifications to its on-media data structures (or their in-memory representations) at all until the meta-data is synced to disk," DragonFly BSD creator Matthew Dillon explained, comparing HAMMER, his clustering filesystem, to a wiki summary of Reiser4's implementations.

He continued:


 

Improving HAMMER Performance

KernelTrap - Kernel news  Thu, 06/12/2008 - 03:17

"After another round of performance tuning HAMMER all my benchmarks show HAMMER within 10% of UFS's performance, and it beats the shit out of UFS in certain tests such as file creation and random write performance," noted DragonFly BSD creator Matthew Dillon, providing an update on his new clustering filesystem.


 

HAMMER Stabilizing

KernelTrap - Kernel news  Wed, 05/14/2008 - 08:11

Matthew Dillon sent out a series of updates about his developing HAMMER filesystem, noting that he is currently focusing on the reblocking and pruning code, tracking down a number of bugs resulting in B-Tree corruption.

He also noted that previously HAMMER was comprised of three components: B-Tree nodes, records, and data.


 

HAMMER Crash Recovery

KernelTrap - Kernel news  Thu, 04/24/2008 - 19:20

"HAMMER is going to be a little unstable as I commit the crash recovery code," began DragonFly BSD creator Matthew Dillon, adding, "I'm about half way through it." He went on to list what's left for crash recovery to work with HAMMER, his new clustering filesystem, "I have to flush the undo buffers out before the meta-data buffers; then I have to flush the volume header so mount can see the updated undo info; then I have to flush out the meta-data buffers that the UNDO info refers to; and,