Re: Cloning using BootIT NG
From: Jim (null_at_null.com)
Date: 04/27/04
- Next message: Steve Nielsen: "Re: Microsoft XP spying"
- Previous message: Patty: "Problem with shadows"
- In reply to: Jim: "Re: Cloning using BootIT NG"
- Next in thread: anonymous_at_discussions.microsoft.com: "Re: Cloning using BootIT NG"
- Reply: anonymous_at_discussions.microsoft.com: "Re: Cloning using BootIT NG"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 27 Apr 2004 12:57:13 -0700
Well, the plot thickens.
As a sanity check (since as I said, I do this very rarely, having an extra
HD around makes this a heck of a lot simpler and faster, using optical media
is just a royal pain), I decided to image my own NTFS partition to CD-R
media using BING 1.60f. The partition contains my OS, is 16GB total, and
~4.3GB used. I imaged the partition directly to some cheap 16x Hi-Val media
w/ my LITE-ON 451S DVD+-R/RW CD-R/RW combo drive. It consumed 4 CD-R discs,
which is exactly what I expected (~ 2-to-1 compression), ~2.4GB. Which is
exactly the same size as when I imaged that same partition to another FAT32
partition for subsequent burning w/ BINGBURN. So wrt your problems,
something is amiss here.
Time for a little more speculation (seems to be a lot of that today).
My partition is highly *de*fragmented. Frankly, I've never trusted that
with any compression algorithm, having a highly fragmented partition would
produce good results. Why? For reasons of speed, I suspect many
compression algorithms are based on sectors. IOW, if a sector contains
*any* data, it's not compressed, simply dumped as is. If the sector is
empty, then it's simple counted, but no data transfer is necessary to the
image file. This makes for a VERY efficient (and interoperable/portable)
process, esp. important when the output is to a highly volatile media like
optical, afterall, that's why we have buffer under-run technology. It also
greatly speeds up verification (unless you specify byte-for-byte
comparison). The idea of going byte-by-byte, sector-by-sector across 20,
30, 60GB of data for compression *and* verification could take a VERY long
time, worse than zeroing out a HD!
Therefore, I'm wondering if perhaps your partition is highly fragmented?!
And what would happen if you defragmented first. I suspect that while you
ate up 9 CD-R initially, it wouldn't have consumed 30, perhaps 12-15.
Perhaps fragmentation was severe enough to cause serious media consumption.
Again, speculating, since I had no problems and have very defragmented
partitions (I can't imaging what else could be different). Hardware,
perhaps, but I don't think BING makes any distinction among hardware.
HTH
Jim
"Jim" <null@null.com> wrote in message news:R2yjc.199$ph.37@fed1read07...
> I just thought of one very, very, very, speculative reason BING has a
> problem with imaging directly to CD-R/RW.
>
> I'd be willing to make a *small* wager that there's something that needs
to
> be known about the image file(s) *before* burning that makes it impossible
> for BING to handle a direct image to CD-R/RW. IOW, perhaps BING needs to
> know the total size of the compressed file(s), number of files, etc., as
> part of some header information that goes on the first CD-R/RW disc. But
of
> course, it doesn't know this until *after* compression is complete. If it
> wanted to support direct imaging to CD-R/RW, it would have to find
someplace
> to store a temporary image before actually burning. But this may not be
an
> available option to everyone, someone may be imaging their entire HD! So
> BING takes the simplest, safest approach and burns without compression (of
> course, at the expensive of media). This would also explain why BINGBURN
> works, it KNOWS all this information before the image file(s) are burned.
> In fact, by imaging to a FAT32 or NTFS partition as I instructed, you've
> done manually what BING probably would have preferred to do automatically,
> but that would perhaps be too presumptive.
>
> I'm not familiar w/ Ghost and how it images, but perhaps its imaging is
> proprietary, does not have similar header dependencies, etc., not like
BING
> does (then again, I'm not sure if BING is using some *standard* imaging
> algorithm either, making it more portable than Ghost?!, again, just
> speculation).
>
> Anyway, I'm suspicious it's something along theses lines. If BING doesn't
> need to do compression, it avoids all the messiness of these other issues
> (is there space for a temp? where can I put it? in some other partition
> for temp purposes?), etc. Again, at the cost of media.
>
> HTH
>
> Jim
>
>
> "Jim" <null@null.com> wrote in message news:nRxjc.198$ph.12@fed1read07...
> > I've been using BING (BootIt NG) for a long time, at least four years,
so
> > I'm quite familiar with it. I don't do much imaging to CD-R/RW, but the
> few
> > times I have, I don't recall any such similar problem (but maybe I never
> > noticed, or my partitions were too small to notice). Most of the time I
> > image either to the same HD (placed at the high-end of the HD, for quick
> > access), or another HD (for recovery in case of HD failure).
> >
> > But assuming this is true, I can think of at least a workaround. Try
> > imaging the partition to another FAT32 or NTFS partition (i.e., as a
file
> > instead of a partition), then load Windows and run BINGBURN (available
> free
> > from TB) to burn the image(s) to CD-R/RW. You won't have any similar
> issues
> > because the files will be highly compressed *before* burning. Yeah, bit
> > more of a hassle, but it will work.
> >
> > I suspect there's some limitation in DOS that makes compression and
> burning
> > difficult or unreliable, maybe BING can't use the buffer under-run
> > technology unless using Windows. I'm just speculating.
> >
> > HTH
> >
> > Jim
> >
> >
> > <arglass@yahoo.com> wrote in message
> > news:06ca01c42c78$50526010$3501280a@phx.gbl...
> > > I recently "rebuilt" my OS from scratch, putting it on a
> > > smaller partition (20 GB) of a 60 GB disk so that I could
> > > just clone a basic setup for future restore. This basic
> > > setup takes all of about 2 GB of this partition (NTFS, of
> > > course).
> > >
> > > I used BootIt NG successfully for the the repartitioning.
> > > However, when I attempted to do a backup image I finally
> > > aborted the session when I got to the ninth disk. Nine
> > > disks?! Why is only 2 GB of data taking up nine-plus disks?
> > >
> > > Seems to me there should be a "data only" image option,
> > > which with Ghost would only span about 3 disks. When I
> > > contacted Terabyte about this, I couldn't get a straight
> > > answer. Either there is or there isn't such an option!
> > > Apparently Terabyte's tech support personnel don't even
> > > know. Too bad, because everything else about the product
> > > seems solid and reliable.
> > >
> > > The comments I've read about BING elsewhere suggest that
> > > making a data-only compressed image is possible, but I
> > > haven't been able to figure this out from the docs.In any
> > > event if it's going to take 30 disks to back up a
> > > partition, then this is not a good option for imaging.
> > > What am I missing here?
> > >
> > > Thanks in advance for any suggestions.
> >
> >
>
>
- Next message: Steve Nielsen: "Re: Microsoft XP spying"
- Previous message: Patty: "Problem with shadows"
- In reply to: Jim: "Re: Cloning using BootIT NG"
- Next in thread: anonymous_at_discussions.microsoft.com: "Re: Cloning using BootIT NG"
- Reply: anonymous_at_discussions.microsoft.com: "Re: Cloning using BootIT NG"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
