Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Data verification software for copying off CF/REDDrive/etc.

Ronx, interesting. But don't you have to read every byte of a source file in order to generate a checksum before the copy? How does yours differ?

Michael

It doesn`t create a checksum. If you`re downloading a large file, using say bittorrent or p2p, checksums help to verifiy that the file you are copying is genuine. We already know our red footage is genuine, because we just filmed it onto our CF card. Its genuine even if our CF card has a disk error, since there isn`t another copy in existance to replace it with (unlike using bittorrent which will seek out an alternative source for the corrupt data). The software is simply written to make sure that what went on the CF is the same as what ends up on my backup drive, so all we have to do is read what is written to the destination disk and compare each byte with what was just read. The comparison is very simple and goes something like this:

if source_byte is not equal to destination_byte then theres an error (report it) else everythings ok (so read and copy next chunk to end of destination file)

This is perfectly adequate, since two bytes can`t be "identical AND different", at the same time (unless you use a drive system based on strange quantum physics, but that technology hasn`t been conceived yet)

You could of course create a checksum, if you wanted, to check your data COPY hasn`t become corrupted at a later stage, but if you`re using a fault tolerant RAID system it will detect and repair errors that occur later on in the files life span, automatically (so we won`t do its work for it).

So, it basically stops periodically (whilst copying) and reads the last chunk of data that was copied, and compares it to the data it just read (while its still in the memory buffer, to avoid having to read input data twice), and keeps doing this till the file is copied. Below is what I wrote in an earlier post on this thread (befoe I actually created the prototype to check I wasn`t talking rubbish, which I never ever do ;)

NB, for any non-programmers reading, files can be opened in READ, WRITE and APPEND mode, explained below.

APPEND allows data to be added to the end of an existing file, like the one we`re creating during copying.
WRITE mode creates a new file (over writing any file that already exists, effectively deleting it during initialisation). We can then write to the file until the CLOSE command is executed (which it must be if we wish to change file modes). This mode is only used once by my software.
READ mode is self explanatory, allows reading any part of the file. I use a command called SEEK to move to any byte location in the file.

1) Buffer some data from file being copied
2) Write buffered data to new file (on hard disk)
3) Close the new file (on the destination disk), then immediately open in read mode
4) Read newly written data from new file (ie goto end of file minus the size of the read buffer), compare to data form original file (still in memory buffer)(display message if data differs)
5) If all goes well, close new file, then imediately open again (in file append mode) or exit (if data error)
6) Repeat process till file copied

done, new file is identical (assuming you don`t have faulty memory!). Using a good size buffer really speeds up disk copies too.
 
Ronx, thanks for sharing the specifics of your copying tool. So this all presumes that the data read from the source media into the memory buffer is without error. I've not worked at the hardware level so I don't know. Is that 100% true?

Michael
 
No shyness here... I'm fearful of over-promising :)

It will come. I hope to have a couple of prototypes in use on real RED shoots within a couple of months, then it should be just a matter of finalising production for retail models.

Sometime along the way I'll shamelessly borrow from RED and take pre-orders (so I can convince my backers that demand exists before we sink big bucks into production).

You know all this 'making stuff' is quite new to me. Seems like fun.
 
The ShotStore certainly looks good but August is a long way off for us :-(
In the meantime, in terms of file verification (which is an essential stipulation from some of our clients) is the simplest solution something like the Nexto which natively checks that everything that's on the CF card comes off it onto the Nexto's hardrive? Could the Nexto then be further backed up onto a laptop (preferably with the more robust & reliable flash memory SSD built in?) or else another external hard drive (Raid 1 preferably?). The original Nexto could then be sent to the editors at the end of the day (everything on that Nexto has been verified), who in turn make their own back-ups (including LTO-3 tape, stored in a separate location to their hard drives). If there was a second Nexto (they're pretty cheap), the crew could carry on backing up onto that the next day until the first Nexto was dropped down to set (having been formatted after back-ups were made at the editors), ready to be used again. The great thing about the Nexto (apart from the built-in file verification) is it's portability and ability to run off battery power when needed (e.g. location filming). They also claim it's the fastest way in the industry of transferring CF cards (don't know whether that's true or not?) Does this workflow make sense to anyone?
 
Nexto

Nexto

I finally got to play with a Nexto 2525 yesterday. A half-full Red Card dumped in 4min 18secs, so about double the time it takes to shoot them. We used a 80G Toshiba laptop drive in the Nexto. (Specs: TOSHIBA MK8032GAX 80GB 5400 RPM 8MB Cache ATA-6 Notebook Hard Drive. 12ms seek time, average latency of 5.55ms)

The Nexto has 2 verify modes. When you remove and reinsert the same card, it offers to verify it. A complete verify on a half full-card took just over 7 minutes. The other verify option is "sample" which took 3 seconds (!) on the same card.

It's a pretty slick little unit and couldn't be simpler. It literally has a 1-button interface, where the your two choices are always a 'short push' or a 'long' one.

I would be comfortable using it for quick and dirty backups in the field, but would not trust it as my only backup source. For example I would use it to copy a card as soon as it comes out of the camera, but I would not reuse that card until I had made an additional backup with a different system.

For the same price as a couple of HDCAM SR tapes each, you could easily treat these drives as the 'tapes' you deliver to post and have 3 or 4 that you rotate between set and the post facility.
 
Could the Nexto then be further backed up onto a laptop (preferably with the more robust & reliable flash memory SSD built in?)

If you could find a PATA SSD you could put a flash SSD in the nexto.
 
Personally I wouldn't mess with the Nexto, I don't think. I'd just use a Laptop with a backup application.

Although I haven't used the Nexto, so I am just speculating really.

The one thing I really wouldn't do is rely on a drag-and-drop copy on Windows or OS X. Not because it's likely to write damaged files, but because if it stops for some reason it's not easy to pick up where it left off. It's also not easy to keep track of what has been copied.

At the moment, I think the best bet is to use a RAID-1 drive unit, copy onto it with a backup util on a laptop, and then treat that drive as an exposed magazine really. Take it back to post facility and duplicate the data to a larger server (RAID-5 perhaps) and ideally make another copy too, or put the original RAD-1 set on the shelf until the end of post when you know all is good.

I'd be making backups of that larger stoage collection as well, every 400GB or so I'd be running off an LTO tape or two.

This workflow is how I'd tackle it now, and is similar to the workflow we hope to achieve with the SolidStore.

As for Nexto's speed - I can't comment, but in an application like that the largest dely is likely to be introduced by the 2.5" HDD inside. It will usually have a writespeed lower than the read speed of cards (certainly the RED cards) and substantially lower than the native speeds of SATA or ATA133.

They are quick in how they process the data I believe, but will still be hampered by the physical constraints.
 
Back
Top