[no subject]

Even from as good programmer as you. UFS is plain indestructible, 
including many of my harsh tests that eg. completely kills ZFS with full 
data loss ;)

Are i-nodes laid out in predefined places or scattered over and accessed 
with tree like structure?

UFS do first, so fsck ALWAYS know where to find inodes. getting 
trash-write on random place would destroy few files but not the whole 
thing.

> :> 3) how about reboots? From my understanding reboot, even clean, means losing
> :> ALL cached data. am i right?
>
>    All swapcache-cache data is lost on reboot.
>
this is quite a disadventage. Of course production system would not crash 
every day, but imagine that crash happened for any reason (power spike, 
lost of power etc.) then i rebooted and it works and now all users wants 
to use server so we get time of highest load and... swapcache is empty.

warmup will take some time and system would be slower that time.

Still ability to manually decide what files are cached is plain great and 
exactly what i need.

And finally losing swapcache device means no data loss. i could risk using 
cheap flash media that have warranty. if it fails, just replace.

> :> In spite of HAMMER being far far far better implementation of filesystem
> :> that ZFS, i don't want to use any of them for the same reasons.
> :>
> :> UFS is safe.
>
>    A large, full UFS filesystem can take hours to fsck, meaning that a

35 minutes for largest i use - 2TB. I ALWAYS(TM) do one filesystem per 
drive or 2 drive mirror, rest are checked in parallel.

This is safe, double disk failure would result of losing 2TB volume, not 
20TB.

>    crash/reboot of the system could end up not coming back on line for
>    a long, long time.  On 32-bit systems the UFS fsck can even run the
>    system out of memory and not be able to complete.  On 64-bit systems
>    this won't happen but the system can still end up paging heavily
>    depending on how much ram it has.

wrong. I've never got more than 500MB RAM per drive. and i always have 
more than 500MB per drive on machine.

i would need to have tens of millions of files per disk. it doesn't 
happen. i never had more than 3 millions.

>    In contrast, HAMMER is instant-up and has no significant physical
>    memory limitations (very large HAMMER filesystems can run on systems
>    with small amounts of memory).
>
this is true and i already tested it.

I could call HAMMER "ZFS done right" but still it is dangerous.

Until i would UNDERSTAND hammer is safe i will not believe it.

HAMMER is really great deal of Your work but if it is a good idea 
(contrary to good implementation) is something else.

> :> thanks
>
>    With some work, people have had mixed results, but DragonFly is designed
>    to run on actual hardware and not under virtualization.

Seems like you missed my question. i DO NOT WANT to virtualize DragonFly.
Just as i dont want to virtualize FreeBSD now.
Today "virtualize everything" trend is plain stupid, and people like 
stupid ideas. i don't.

But i run few windows sessions using VirtualBox UNDER FreeBSD. Without 
such option i would need separate machine for it.

for everything else i use jails, and DragonFly have working jails.