Can filepro do drill downs like acess?

[Jay R. Ashworth]

On Fri, Mar 26, 2004 at 10:19:48AM -0500, Bill Vermillion wrote:
> That's one reason they were developed. When these were almost
> standard for serious operations - sales for example - drives were
> not that reliable and hardware wasn't that stable - even the best
> of the HW.  These were all on Unix systems BTW.  Hard drives were
> about $4/megabyte if you shopped, or if vendor supplied were
> in the $8/megabyte range. [A far cry from the $1 Gigabyte 
> we see today for server strength IDE drives [ 50 cents or less for
> consumer/desktop drives].  The high-end high-capacity SCSI's are in
> the $6+ per GB.

Seagate's Cheetah-164 is about $800 right now.  That is, actually, $.50
a gig.

> So on boot a snapshot is made of the drive in it's current state.
> Multiple parallel fsck's are started in the background and the
> system is brought up for use.  Everything not fsck in the
> background is essentially in a read-only at this moment.
> 
> But if a user program needs access the blocks needed are
> essentially fsck'ed at that point.  IOW the fsck is prioritized to
> fsck blocks as needed. It will update the snapshot made at boot
> so these are now excluded from the background fsck.
> 
> In tests an fsck which might take 15-30 minutes if done at boot -
> even with parallel fscks running - when run in the background it
> could take 5+ hours.  But the system is avialbe immediately for
> use.

Actaully, mostof that is being done with journalling filesystems, these
days, which are effectively the application of transactions to
filesystem updates: the filesystem structure's sanity is preferred at
the expense of the data, in the event of a crash.

> > Row+Column locking? That could be handy. I think column locking
> > alone would be useless, but if you combined row and column,
> > that would be the ultimate. I wonder how much overhead that
> > generates though...
> 
> I don't know. For some reason I think this was in Oracle or
> one of their competitors at one time if not now. Overhead is
> not a problem - because in these instances the system has been
> optimized so that users don't remain idle waiting for someone
> else to finish with something they need to access. Once you
> exceed a certain number of users hardware and software costs
> become secondary to the costs of idle users.

You don't really *want* to do that, though; code tends to make an
assumption that a row is interenally consistant; allowing multiple
updates on parts of the same row without MVCC or something breaks that.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson