Forensics Workstati...
 
Notifications
Clear all

Forensics Workstation

8 Posts
5 Users
0 Reactions
768 Views
(@bluepup)
Active Member
Joined: 19 years ago
Posts: 10
Topic starter  

Hi Guys,

Im pretty new to this and I just wanted to get some opinions and advice from some of you more experienced guys out there. Im in the process of building a forensics machine and like most companies, I have a limited budget. The motherboard I have chosen has the ICH7R southbridge controller which allows for the Intel Matrix Raid to be configured. As I dont have the funds to purchase a dedicated Sata raid controller card, i was thinking of utilising this feature as I've heard that you can get some decent read/write times if you place your os and applications on one volume (raid 0) and all other data on another volume(raid5). So bascially Raid 0+5 over 3 hard disks.

have you guys any negative thoughts on this?

Bobs


   
Quote
(@fobitt)
New Member
Joined: 19 years ago
Posts: 1
 

Disk I/O is one of the big bottlenecks I always run into. Right now I am running two western digital raptors in RAID 0 for the OS, tools and any VM's I might be running. For the data I am working on, I put in two 500GB drives also running RAID 0. The good news is that even relative cheap controller cards (and some of the better motherboards) will do RAID 0 without a problem.

The other thing you want to look at is external hard drives. You may have to acquire from a machine on to an external drive for a number of reasons. Right now the fastest option is external SATA. That makes an external drive just as fast as an internal and is definitely worth it. One step down is Firewire 800… which I think is going to be the new Zip disk. Not because it doesn't work well, just because it hasn't taken a serious hold on the market yet, and eSATA is faster and usually cheaper.


   
ReplyQuote
steve862
(@steve862)
Estimable Member
Joined: 19 years ago
Posts: 194
 

Hi,

I did a little testing a while back to establish some speeds when performing specific tasks we frequently do. I found that USB frequently dropped below the maximum transfer speeds and that internal disks performed significantly better (even IDE ones). With SATA 2 on most motherboards now a decent cheap option is to have all data go on those drives and as was suggested have the OS striped accross a couple of 10,000 rpm drives on a separate controller.

There have been a couple of other threads on this subject not so long ago so try looking back through the forums for other info.

FTK 2 comes out soon and will be 64bit. Rumours are EnCase 6 will support multi processor and will be 64bit.

Steve


   
ReplyQuote
(@bluepup)
Active Member
Joined: 19 years ago
Posts: 10
Topic starter  

Thanks for the info on the drive alternatives and I will take it into consideration for future cases.

But I've just built the company's first "forensic" workstation and gone ahead and taken 20gb from each hdd to create a 60gb raid 0 array for the os +apps and the rest (560gb) on a raid 5 array for the data with the intel matrix setup. The hdds i used were seagates 7200.10 series

The currents setup of my workstation is that the hdd im acquiring an image from is in a ide drive caddy which is connected to the write blocker which in turn is connected to the system via firewire800. The system has a core2 duo chip with 2gb matched pair memory running on a decent mb.

Im not sure what to expect in terms of performance, but using ftk imager to acquire an 80gb 7200rpm hdd, im getting roughly… 450mb/min. To me, this seems slowish however I am relatively new to this. (and I am comparing this to the speeds i was getting using a dedicated portable hdd imager as I was getting on avg 1-2gb/min(logicube talon))

Does this sound about right to you guys??

Fobitt and Steve, maybe I Should configure the 2nd array to run raid 0 to get better speeds? The intel matrix raid is running off the Asus P5W64 WSPro so i think its quite reliable..

Bobs


   
ReplyQuote
(@gmarshall139)
Reputable Member
Joined: 21 years ago
Posts: 378
 

1/2 gb a minute does seem slow. I have always averaged around 1 gb per minute using firewire 400 to firewire 400 acquisitions. Are you running imager from the hard drive?


   
ReplyQuote
(@degan24)
New Member
Joined: 19 years ago
Posts: 2
 

I have an Intel MB with that controller as well. The only OS that would recognize the BIOS configured raid arrays was XP or Server 2003. Linux didn't recognize it. The only Linux that worked properly with the ICH7 in a raid configuration (md) (non-matrix raid) was Suse Enterprise 10. It is the Intel 945GTP with a Pentium D 940. Anyone want to buy it cheap.

Keep in mind that the Intel Matrix Raid is still software raid. There is no raid specific CPU. There is a ROM on the motherboard, but it just a ROM. The raid is still 100% CPU managed.

For me, Raid1 for your OS files and Raid 5 for your data storage is the way to go. Softraid is plenty fast and leaves enough CPU for forensic work.


   
ReplyQuote
(@bluepup)
Active Member
Joined: 19 years ago
Posts: 10
Topic starter  

gmarshall

im running imager from the raid 0 array. the images are being written to the hdd in the raid 5 array. like i said… im not too sure what to expect but I know what im getting at the moment seems a little too slow.

any ideas on where the bottleneck is occuring?

degan the idea is there but it doesnt seem to be living up to the performance expectations of a matrix raid. my cpu is barely getting over5% during the imaging process. i'd prefer to keep the os files on raid0 for better performance, i dont need to mirror it.. if something should happen (god forbid), i've ghosted off an image of the os+apps which can be dumped back on in less than 5minutes….


   
ReplyQuote
(@degan24)
New Member
Joined: 19 years ago
Posts: 2
 

It shouldn't take much CPU to copy from disk to disk. Bottlenecks come in when you have both drives on the same controller. Also, the quality of the driver come into play. What is the block size that is being transferred. You can play with 'dd' (you can run this under cygwin on XP) to see the effect.

We tend to think of block size as the sector size of the disk. But from the drivers point of view, the block size can be almost anything. If the driver supports DMA, then you want the block size to be as large as possible. The cpu overhead for a block size of 512 bytes or 64K bytes is the same. But obviously transferring 64Kbytes as a single block will take much much less time than 128K 512 byte transfers.

'dd' lets you control this. I don't know if other imaging programs allow this.


   
ReplyQuote
Share: