different bridge for each host drive interface, or adapters?

Hello -

Bumping this up to see if anyone knows or is willing to kindly help me on this. I trust there is a good reason that people don't seem to generally go the bridge route and rather prefer to use the same protocol write blocker instead, but I would like to understand the reasoning.

Cheers

A you hit the nail on the head when you pointed out that it would be more expensive to have specialized write-blockers/bridges. The only reason you want to have multiple devices is if you have to image drives in parallel (which, in my experience, is pretty common). That being the case, you probably want to be able to capture multiple IDE, SATA drives, etc., in parallel, so the best solution, IMHO, is to have several write-blockers, each with multiple interfaces.

If imaging speed is important to you then do not neglect to consider how the write blocker connects to your imaging computer. I have found that a write blocker connecting to an imaging computer via eSata will image a drive about 5 times quicker than one using USB 2.0.

I have not tried a USB 3.0 write blocker yet but I believe a similar speed increase can be expected compared to USB 2.0.

This could be important if you do a lot of imaging on site and can be the difference between spending an evening at a premises to spending the whole weekend there.

When I started my own consultancy, I bought an UltraKit - 2 IDE/SATA bridges, a SCSI bridge, and a USB bridge, with adapters for different SCSI connectors, and for laptop drives. I've subsequently bought a ZIF adapter that works with the IDE/SATA bridge and acquired additional IDE/SATA bridges. I haven't run across anything in the field that didn't work with the kit that I have, or that I couldn't handle with a boot disk solution.

I would be careful with attaching an adapter to a bridge for a drive type that the bridge does not understand as you then couldn't necessarily predict the behaviour, and you'd need to do more extensive testing than usual to validate all the possible usage scenarios.

If you need to image one of the latest Apple SSD drives it is worth buying a convertor like the one below.

I have just purchased one for a new MacBook Pro that I had to examine and it worked fine.

http//www.amazon.co.uk/gp/product/B00AZLV8BY/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1

I would be careful with attaching an adapter to a bridge for a drive type that the bridge does not understand as you then couldn't necessarily predict the behaviour, and you'd need to do more extensive testing than usual to validate all the possible usage scenarios.

Tony brings up another argument in favor of fewer, rather than more, devices – you want to have validated that they work. The more different devices you have, the more validation effort required.

If imaging speed is important to you then do not neglect to consider how the write blocker connects to your imaging computer. I have found that a write blocker connecting to an imaging computer via eSata will image a drive about 5 times quicker than one using USB 2.0.

I have not tried a USB 3.0 write blocker yet but I believe a similar speed increase can be expected compared to USB 2.0.

This could be important if you do a lot of imaging on site and can be the difference between spending an evening at a premises to spending the whole weekend there.

'

It's very important to me, yes. I've been 'studying' (but not yet testing) some concepts relating to speed lately and what I have come up with to posit at this point is the following

Assuming newer kit with, say, a DI UltraBlock USB 3.0 IDE-SATA Write Blocker or the eSATA version, reasonably modern laptop with SATA II or SATA III bus …

During acquisition -
speed will most often be limited by the read speed of the source drives (esp assuming one acquires to modern HDD) – as most non-SSD drives cannot saturate the new data buses used.

If there is need to to copy image to working area -
speed will most often be limited by the speed of the image target drive used – as most non-SSD drives cannot saturate even a SATA I bus and certainly not a SATA II bus.

Then, when working with the data in whatever application you use -
- my impression is that of course the application itself may be a bottleneck (such as in the case of Encase using only a single processor thread rather than being multi-threaded even to do the initial indexing…).
- Also though that you might be 'limited' by the latency of storage configuration rather than the throughput bus used. So, as far as I understand it, USB (even 3.0) introduces much more latency over SATA/eSATA due to how the protocol is written. So, if I were working with the data over an external bus, I might find eSATA (275 MB/s with lower latency) preferable to USB 3.0.

So, other things being equal, USB 3.0 or eSATA would work quite well for host connection during acquisition and data staging but eSATA might be better in some applications for actually working with the data – if working over an external bus as opposed to working with the data from an internal direct attached storage.

Does this match with expert experience out there?

A you hit the nail on the head when you pointed out that it would be more expensive to have specialized write-blockers/bridges. The only reason you want to have multiple devices is if you have to image drives in parallel (which, in my experience, is pretty common). That being the case, you probably want to be able to capture multiple IDE, SATA drives, etc., in parallel, so the best solution, IMHO, is to have several write-blockers, each with multiple interfaces.

So, if I understand correctly, and I'm oversimplifying here a bit, assuming I want the general capabilities to capture 4 drives concurrently, I might purchase 4 write blockers (of the newest bus, feature type I can get – like perhaps the new USB 3.0 host side write blocker from Digital Intelligence). Those do SATA and IDE drives, and if I want to be prepared to do others such as SAS, for example, I could indeed in theory use a drive adapter, but it would require some additional validation to make sure that the write blocker works properly with the suspect drive(s)?

By 'work with', is what is meant that there could be serious implications of forensic nature .. such as the write blocker not having been able to block writes to the host drive when used in conjunction with the host drive interface adapter?

Or, are just saying that it simply might not work at all, as in not recognized, for example?

Thank you (all) very much for your comments, btw. I'm finding all the info on this forum extremely helpful and interesting, I must admit.

When I started my own consultancy, I bought an UltraKit - 2 IDE/SATA bridges, a SCSI bridge, and a USB bridge, with adapters for different SCSI connectors, and for laptop drives. I've subsequently bought a ZIF adapter that works with the IDE/SATA bridge and acquired additional IDE/SATA bridges. I haven't run across anything in the field that didn't work with the kit that I have, or that I couldn't handle with a boot disk solution.

I would be careful with attaching an adapter to a bridge for a drive type that the bridge does not understand as you then couldn't necessarily predict the behaviour, and you'd need to do more extensive testing than usual to validate all the possible usage scenarios.

Thank you; this is useful.

It looks part of my reply, the part about the interface adapters, to TuckerHST should have been addressed to you also as you commented on this. My apologies.

Should I be concerned about any forensic type of issue such as the host interface adapter preventing the write blocker from blocking writes? I don't think so, but I should certainly ask!

Cheers