Hi,

It's great to see this project so close to completion! I'm trying it out on a couple machines to see how it goes.

A few comments and questions:

* It took me a little by surprise that it carves 1G out of the device for the journal. Depending on the size of the device that can be a pretty hefty price to pay (and I didn't see any mention of it in the setup notes). For a couple of my smaller filesystems I reduced it to 512MB. Perhaps some algorithm for auto-sizing the journal based on the size / expected workload of the device would be in order?

* Attached is a quick patch for geom_eli to allow it to pass BIO_FLUSH down to its backing device. It seems like the right thing to do and fixes the "BIO_FLUSH not supported" warning on my laptop that uses a geli encrypted disk.

* On a different system, however, it complains about it even on a raw ATA slice:

atapci1: <Intel ICH4 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: <ATA channel 0> on atapci1 ad0: 114473MB <WDC WD1200JB-00CRA1 17.07W17> at ata0-master UDMA100 GEOM_JOURNAL: BIO_FLUSH not supported by ad0s1e.

It seems like a reasonably modern controller and disk, at least it should be capable of issuing a cache flush command. Not sure why it doesn't like it :/

* How "close" does the filesystem need to be to the gjournal device in order for the UFS hooks to work? Directly on it?

The geom stack on my laptop currently looks something like this:

[geom_disk] ad0 <- [geom_eli] ad0.eli <- [geom_gpt] ad0.elip6 <- [geom_label] gjtest <- [geom_journal] gjtest.journal <- UFS

I was wondering if an arrangement like this would work:

[geom_journal] ad0p6.journal <- [geom_eli] ad0p6.journaleli <- UFS

and if it would be any more efficient (journal the encrypted data rather than encrypt the journal). Or even gjournal the whole disk at once?

Haven't been brave enough to try gjournal on root yet, but my /usr and /compile (src, obj, ports) partitions are already on it so I'm sure I'll try it soon ;)

Craig