Date: Wed, 30 Nov 2016 03:06:59 -0800 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: FreeBSD Questions Mailing List <freebsd-questions@freebsd.org>, freebsd-fs@freebsd.org Subject: Re: Calculating size of a corresponding ISO9660+UDF image? Message-ID: <CAOgwaMvdtB8aD1QrFu_pPoPA5V0Ra7abYqbNnbABO39KfqL6sA@mail.gmail.com> In-Reply-To: <25788.1480501137@segfault.tristatelogic.com> References: <25788.1480501137@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 30, 2016 at 2:18 AM, Ronald F. Guilmette <rfg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMvdtB8aD1QrFu_pPoPA5V0Ra7abYqbNnbABO39KfqL6sA>