Settings for data archiving (to BD-R)?

[ronbaby]

I'd like to use my BluRay burner and the blank BD-R disks I have to create backup copies of all of the (essentially arbitrary) data files that I have stored on one particular disk drive and under one particular directory (over on my FreeBSD file server, which is Samba-exporting the relevant filesystem to my Windows7 system, where I run ImgBurn).

 

I've already written a small Perl script which breaks up this great mass of data files into appropriately sized (25GB/23.3GiB) chunks such that no single file will be split across two of the target BD-R disks.  This will make it easier to recover single files from the backup(s)  should that ever be necessary.

 

What I've just now realized is that although I have been using ImgBurn happily for years (for DVD backups) I actually don't know what I'm doing when it comes to using this fine tool for data archiving.

 

Specifically, I am utterly confused about all of the available "Image Options", and would like some guidance.

 

For this specific (data file archiving) aplication, what would be best?  ISO 9660?  UDF?  Joliet?  All of the above?  I'm totally in the dark.  My only requirement is that the resulting burned BD-Rs should be readable on Win7 and also on recent vintage Linux systems.  (It would be Nice if they were readable also on recent vintage FreeBSD systems, but that's not a hard and fast requirement.)

 

Also, with respect to UDF, I am being offered (by Imgburn) the choice of no fewer than six different UDF revision numbers.  I have no idea which one of those will be "best" in this case, and don't have any idea what the pros and cons of the different versions are (and the ImgBurn guides and FAQ don't seem to say anything specifically about this).  I've looked also at the summary of the UDF revisions on the applicable Wikipedia page, but it is all still rather opaque to me.

 

And last but not least should I just stick with the default of "MODE1"?  What is "MODE2" used for?  Is MODE2 adding more error correction data?  If so, I might want to use that.

 

Advice on all of these points would be appreciated.

 

P.S.  The one useful tidbit of info that I was actually able to gleen from the ImgBurn guides regarding the above topics was that ISO 9660 permits only ancient DOS 8.3 filenames (yecch) which would be totally non-usable for me, but that Joliet allows filenames up to 64 bytes (characters?) and UDF up to 128 bytes (characters?).

 

Of course, this all sort-of encourages me to use just straight UDF, but it also begs the question:  What will happen if I have a file in a  directory that has a 129-byte long filename and if I then ask ImgBurn to burn that (In straight UDF format) ?  Will the filename just get silently truncated??  That would be Bad.  And also, do these limits apply to just the filenames, or do they apply to the complete pathnames?

 

Thanks in advance for any & all replies.

 

[dbminter]

I use Mode1, UDF 2.60 for all of my data archives to Blu-Ray media formats.  However, I don't know anything about Linux, so I don't know if UDF 2.60 is supported on it. 

 

 

I would think these options should make a disc readable on Windows 7. 

 

 

I've used these options for Windows 8.1 Update 1 and all flavors of Windows 10 that have been released without problems accessing the data on the discs later.  I know this is forwards compatible with Windows 8.1 Update 1 and all versions of Windows as discs I've created on Windows 8 were readable on Windows 10.  Your instance, though, is backwards compatibility, so I'm not certain on that.

 

 

I don't know the difference between Mode1 and Mode2.

 

 

If a file name is too long, ImgBurn should notify you before it starts creating the image after you press the "burn" button that it's too long.  It will tell you the file name/folder structure and ask you if you want to continue.

[dbminter]

Found this:

 

http://www.cdrlabs.com/forums/mode-versus-mode-discs-t8075.html

 

 

Seems the difference between the 2 modes is Mode1 has more error correction built in.  It devotes more available disc space to error correction than Mode2.  Mode2 will let you store more data on a disc than Mode1, but you sacrifice the extended error correction in Mode1.

 

 

So, you probably do want Mode1 versus Mode2.

[LIGHTNING UK!]

Mode 2 is only for CD.

[dbminter]

Hm, interesting.  You'd think Mode 1 would have been only for CD's since CD's came first.  Therefore, you'd think the first mode would be for CD's and thus Mode 1.

 

 

Ya loin sumtin new every day. 

[ronbaby]

Thanks for all the replies folks.  Most illuminating.

 

Now, if I could just figure out a nice formula for predicting, based on the set of input files (and paths) how many sectors (on the BR-R optical media) Imgburn will decide to use for the corresponding (UDF 1.02 only) image, I'd be in heaven.

 

I'm starting now to try to reverse engineer exactly such a formula, based on empirical testing.  I'm doing that just because I do not relish the prospect of having to find the actual detailed specs for the UDF format and then groveling through that for hours on end.  (And anyway, even if I did, all of the information might not be a precise predictor of what ImgBurn will actually do.)

 

I hope that my formula will end up being reasonably simple... something like:

 

    UDF image size = roundup_mod_64k (actual data blocks) + (per-file-overhead * files) + general disk overhead

 

but I already have some hints from my testing that things may not be so simple.

[dbminter]

What does the 2048 number next to Mode 1 mean in the settings?  It's a multiple of 1024, so it's a binary value, that much I know. 

[LIGHTNING UK!]

bytes per sector

[ronbaby]

Yea.  For BD-R sector size == 2048 bytes.

 

However as far as most things relating to BD-R, go, that number is almost entirely superflouous and useless, because in reality, the only things every written to BD-Rs are clusters of sectors, comprised of 32 sectors.  In short, the real block size for BD-R is 32*2KiB == 64KiB.

[LIGHTNING UK!]

Files, file system descriptors etc don't start and stop on 64KiB boundaries, they start and stop on sector boundaries. So you can hardly call that value useless!

 

You only use the block size at the very end of the image for descriptor placement.