Are you using Bit torrent or any third party add-ons?
Which drives are you using?
Have you tried removing each drive, attaching them to a PC and running manufacturers diagnostics or viewing SMART data if that's an option?
Have you tried a factory reset of the unit? You won't loose your data doing any of these things, but you should have a backup just in case.
Are you running the latest firmware?
Does the problem happen if you connet a network cable directly between your NAS and computer?
Just a few things to try 
Thanks--- these are sorta helpful, if I had a computer I could hook these drives up to..... I'm running the latest firmware (1.03). I'm using 2 1TB Barracude 7200 drives. I haven't tried connecting a cable directly to the computer though, but that's not really a solution. I guess it would tell me that my network is somehow negatively influencing my NAS, but......
I've continued to try various things. It turns out that my right drive failed the SMART test. So I powered down and removed it, so I could back up my data. But much to my surprise, many of the directories were missing(!!!) So I panicked a little and tried inserting the other drive into the left slot, and it appears that the missing data is on this drive (thank god.) But it's all very disturbing......
So I reassessed what I've seen so far---
1) DNS-321 worked great for a month with ext3 and raid 1 config.
2) I accidentally cut power to the drive without shutting down.
3) since (2), it's been acting flakey, like described--- it sits there and crunches most of the time with the fan running and sometimes I can't access the data volume, even though I can ping and login to the admin page.
4) One of the drives has many directories *missing*.
I've decided that I'm going to rebuild my volume from scratch, using ext2 instead of ext3 because I found this on http://en.wikipedia.org/wiki/Ext3:
No checksumming in journal
Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.[31][32]
Consider the following scenario: If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or unrecoverable crash should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the "winners" (transactions with a commit block, including the invalid transaction above which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. There is a test program available to trigger the problematic behavior. If checksums had been used, where the blocks of the "fake winner" transaction were tagged with a mutual checksum, the file system could have known better and not replayed the corrupt data onto the disk. Journal checksumming has been added to ext4.[33]
Filesystems going through the device mapper interface (including software RAID and LVM implementations) may not support barriers, and will issue a warning if that mount option is used.[34][35] There are also some disks that do not properly implement the write cache flushing extension necessary for barriers to work, which causes a similar warning.[36] In these situations, where barriers are not supported or practical, reliable write ordering is possible by turning off the disk's write cache and using the data=journal mount option.[37] Turning off the disk's write cache may be required even when barriers are available. Applications like databases expect a call to fsync() will flush pending writes to disk, and the barrier implementation doesn't always clear the drive's write cache in response to that call.[38] There is also a potential issue with the barrier implementation related to error handling during events such as a drive failure[39]
So.... not sure if this applies. I'm going to install fun_plug (http://wiki.dns323.info/howto:fun_plug) so I can checkout fstab.
I'm not getting that loving feeling from my NAS though. I'm also not sure how much extra protection I'm getting from raid 1 on this guy. It seem that a simple power loss has sent my drive into the weeds........ maybe there is someone at D-link that finds this as disturbing as I do.