your are dumping a lot of bits to your hard drive, if you only have 1 drive and are doing things such as listening to music, download, or what not you are using another part of the hard drive, it could miss 1-2 bits here and there because you are causing arm and blatters to work to their max
I've heard people say that before; that is why I asked the question. Hardrives, even over firewire, do not work in a way that you could lose a bit or two somewhere. It is not a stream protocol between the drive and the host where bits get dropped due to the host processor being overtaxed and too busy to service the stream. Reading from a harddrive is a block access protocol with the host requesting blocks from the drive controller via the firewire link, so there should never be a problem except at the block level.
I understand that there could be issues if there are too many things hanging off the firewire controller, but I would expect that to cause more of a problem with throughput or block buffer overfolws if the combined traffic oversubscribes the fw controller.
Matt, yes you can MD5 the files in place on the 722. If you were to do that and then MD5 the files after they were transferred, it would ensure that they were correct (assuming that the errored blocks are random). If you don't have faith in the 722 firewire drivers, that would be a good way to do it. If you want to exercise the 722 to build confidence, you could just write a script to md5 a bunch of files repeatedly and then bark if the script detects a mismatched MD5 on a subsequent pass. That would detect errors appearing in random blocks. If you want to test against the case of repeated errors, you can transfer to the host, then transfer a copy back to the 722 and MD5 the file and it's copy off the 722 compared to the copy left on the host. It's possible but unlikely that the transfer back would exactly undo any original error.
Topic: 722 Issue (Read 8569 times)