DragonFly users List (threaded) for 2005-03
Re: dragonfly pdf documentation
424acdff$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <424ad609$0$720$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <424ad8f3$0$716$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1112202428 crater_reader.dragonflybsd.org 720 18.104.22.168
Xref: crater_reader.dragonflybsd.org dragonfly.users:2569
Hummel Tom wrote:
>>FWIW, I would probably boot from and store webpages
>>on XFS and SQL DB's and other files on JFS even with
>>a *BSD - if the choice were there.
> Keep in mind XFS is the fastest FS for Linux when it comes to big files,
> for a database file i'd rather choose XFS, whereas for more smaller
> files JFS seems to be much faster.
Depends on how your DB-of-choice stores to the fs. Some
use myriad small files, some large 'container' files, and some
use heaps, B+ trees or linked-lists.
Also - if the DB is at all 'transactional' (PostgreSQL, ZODBC)
you do not want 'softupdates' or 'lazy writes', as the DB
has it own buffer management. PostgreSQL WAL will be
faster w/o softupdates, and most robust, if a tad slower
on its own spindle with the SCSI RAID cache set to
'write-through' and UFS mounted 'sync', as well.
The 'default' settings, OTOH, will be quadruple-buffering:
- Memory & WAL, lazy-write/softupdates, SCSI controller
cache, HDD cache.
>>JFS(2) was developed 'clean sheet' on OS/2, backported
>>to IBM Power architecture machines, but never renamed
>>to 'JFS2' on Warp.
> so JFS1 is not what Linux is having inside the kerneltree?
AFAIK, JFS1 never left IBM and Power Architecture. The
IBM 'donation' was JFS2 code, and AFAIK, is still not
suitable for a boot device. As Linux has more in common
with SVR4 than *BSD, and as AIX-5L is 'Linuxified'
so as to be able to run multiple, (complete, not emulated)
'native' Linux instances in dynamically controlled partitions,
one would expect the porting to Linux to have been easier
than to a *BSD (still not here?).
Not to mention IBM having a *substantial* staff of their
own assigned to Linux coding. Grown-ups, even ;-)