Calculating size of a corresponding ISO9660+UDF image?

[Mehmet Erol Sanliturk]

On Wed, Nov 30, 2016 at 2:18 AM, Ronald F. Guilmette <rfg at tristatelogic.com>
wrote:

>
> I just got my first BluRay burner & a ton of blank single-sided BD-R
> media, so I want to start using these for making backups of most or
> all of the stuff I have on hard drives, which is a lot.  But efficiently
> splitting up all of my stuff into nice neat little <25GB bundles seems
> like it might be a bit of tricky problem for two reasons.  (See below.)
>
> (If I can't find anything off-the-shelf that will do this job for me,
> then I plan to roll my own, either in Perl or C.)
>
> The burning itself is no problem.  I plan to use Imgburn.  It is well
> regarded, and it's always worked well for me.
>
> The real problem is one that I have arguably created for myself...  I
> never want to have to read multiple burnt optical disks in order to
> retrieve a single desired file from my backups.  So I never want to
> split any individual input file across multiple backup volumes.
>
> Given that small limitation, I am faced with these two modest technical
> problems:
>
> 1)  How to perform "bin packing" to get as many files onto each blank BD-R
> disk as possible without exceeding the 25GB limit.  (This "bin packing" is
> said to be an NP-hard problem, but I'll muddle through this part somehow,
> even if I end up having my program just try all possible packings. I wasn't
> in a hurry anyway. :-)
>
> 2) How to calculate exactly how much space in the proposed ISO9660+UDF
> image
> the files that have so far selected for inclusion will actually occupy.
>
> Really, it is just this second problem that I care about at the moment.
>
> So, can anybody tell me the magic formula which, when given a set of
> on-harddisk files and directories, will calculate exactly how big that
> set of input files/directories will be, once they are all rendered into
> a single  corresponding ISO9660+UDF image?
>
> If anybody can tell me how to do this calculation, please proceed.  I'd
> really rather not have to get down on my hands and knees and spend time
> groveling around in the bowels of the FreeBSD optical disk drivers in
> order to find this information if I can avoid it.
>
> I mean it can't be THAT complex, now can it?
>
>
> Regards,
> rfg
>
>
> P.S.  This whole problem... especially the "bin packing" part... feels like
> something that somebody else... or maybe a lot of somebody elses... must
> have already solved a long long long time ago, and probably many times.
> So maybe I just need to find and resuscitate some of those old solutions.
> I mean we've been making backups to finite and predictable length tapes
> for at least 50 years now, and I can't be the first guy to have ever said
> that I don't want to split files across multiple backup volumes.  So
> where's
> the off-the-shelf open source freeware to solve the bin packing problem
> for backup tapes?  I'm not proud.  I'll just re-use that code, thank you
> very much.
> _______________________________________________
>
>


I think you may know the following pages and their linked pages :


https://en.wikipedia.org/wiki/Bin_packing_problem
( Bin packing problem )


https://en.wikipedia.org/wiki/Cutting_stock_problem
( Cutting stock problem ) <------------------------------------------- This
is more relevant for minimum backup media numbers .


https://en.wikipedia.org/wiki/Category:Packing_problems
( Category:Packing problems )



Mehmet Erol Sanliturk