On Tue, 10 Aug 1999, Mike Horwath wrote:
- The inability to add quotas without stopping and starting the quota system (You can modify sizes of existing quotas, but cannot add quota restrictions without stopping and starting the quota system).
This one I don't get.
I currently add people to our system and don't see the problem you describe.
Really, what is your procedure for adding new lines to the quotas file? More specifically, what do you do after you add lines to the quotas file? Which rev of DOT do you use?
I'd recommend them over Auspex for their simple and robust OS, clearcut hardware design, ease of use, and speed of cleanup after a crash. With NetApps I had no cleanups; yank a cord, plug it back in, and it continues chuging within 2 minutes. Try that with an Auspex. Similar is true with many directly attached devices.
Care to give more detail to this?
I ask because Auspex was just at my office touting their new NS2000 at a price point that I haven't seen before.
OK, here come the rants.
The NS2000 is composed of at least 4 processors. The Host Processor is built using an UltraSPARC (~300 MHz). In my opinion this piece is completely unnecessary as it provides marginal functionality to an appliance that should serve NFS. The OS running on this piece of hardware is hacked up Solaris 2.6. Then there are Network/File System Processors. These are based on 2 Pentium II's and run whatever OS Auspex managed to write or hack for them. Thirdly, there is the Environmental Monitoring unit based on a 386. Obviously that runs yet another OS, probably very simple and firmware based. What next? Oh, Auspex uses SCSI controllers (this is bad enough in my opinion) that have three SCSI channels. The way they would like to connect their shelves is 1 channel per 7 drives, but their shelf configuration holds 28 drives so you end up connecting the first channel to two shelf units (14 drives) and the remaining two to the remaining 14 at 7 a piece. What a hack, really.
A nasty reboot (power outage) involves rebooting the Host Processor which then uploads the proprietary OS to the NPFSP (Network P./ Filesystem P.). Then each NPFSP _must_ perform a fsck. Oh, I forgot to mention. Their log filesystem only logs metadata and their snapshots are not done in place like they are on a NetApp but copied out of the filesystem. A NetApp allocates another block on write and updates the inode; an Auspex copies the old block to a separate partition and then overwrites the original block. That's two writes in contrast to one. Sure Auspex direct disk reads may be faster, but they already cache about a quarter GB of data in memory so you get no benefit from it with volatile filesystems. The NetApp has enough time to read ahead blocks that are not contiguous, they also have an opportunity to place new blocks close to the rest of the file; WAFL means write anywhere, that includes writing near the old blocks, something I'm certain NetApps attempt to do in their block placement algos. In short I find the Auspex design messy and kludgy. The benefits, if any, appear to be miniml and are outweighted by increased opportunity for things to break (The more things there are to break in series the more likely the system is to break).
Tom