[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-nfs
Subject:    OT: Re: [NFS] Re: NetApps et al. <- NVRAM
From:       Eric Werme USG <werme () alpha ! zk3 ! dec ! com>
Date:       2000-07-27 17:21:49
[Download RAW message or body]

  Not to get too offtopic here, but where would you place such a beastie
  (nvram accelerator)?  In knfsd, jfs'd vfs layer (if that ever comes
  around), ext3 (or other jfs), or raw.c?

  It would be neat add-on hardware for linux.  But it would have to be large
  to serve people nowadays.  I'd hate to have it tied to knfsd, as I do as
  much traffic via smb as I do nfs.

It should be spliced between the file system and the disk device
driver.  Or next to it and the FS select where to write data.  (And
read data no longer in the system cache.  While NFS V2's lousy write
performance was the driving force behind Presto, it sure is nice to
have "rm -rf big.hierarchy" run 80X faster on a local BSD FFS with
only a few disk seeks to read the directories, inodes, and bit maps.

BTW, Compaq has a PCI Presto board, but it's being phased out.  As we
migrate to big servers with shared SCSI buses, no Presto zealot was
around to argue for Presto boards that could failover to another
server with the disks.  Also, to help with Spec/SFS figures, it would
take boards with a lot more RAM than we've had.  Besides, disk
controllers now have NVRAM, even though they don't let you do things
like cache metadata and allow data writes through, at least not as
easily the file system can.

The best Presto board we had was for an Ultrix box that plugged into the
memory bus.  NVRAM on an I/O bus is fairly inefficient unless you can
have disk writes read the NVRAM directly.  Even then, you wind up doing
a lot of extra PCI transfers for all the disk writes saved.

[prev in list] [next in list] [prev in thread] [next in thread]