Re: Unidentified subject!
Joerg Schilling wrote:
Bill Davidsen <davidsen@tmr.com> wrote:
I recommend you to read the documentation from cdrtools to learn that your
claim is not true: cdrecord of course can burn from a pipe.
To be more correct, cdrecord can not burn from a pipe with anything
useful writing the pipe, while growisofs can. cdrecord requires that the
You seem to have an narrow and incorrect sight of the world....
In the same narrow minded manner, I could claim that you cannot
do anythign useful with growisofs (see below.....).
total size of the data be known before starting, which means that the
usual benefits of using a pipe are not possible:
* avoid having to write an image to disk when space is tight
* allow overlapping of image creation and burning time
* allow burning data which changes in size between observation
This is if course not true, see below for more information.
You ignore the first case, I assume you agree it is correct.
You ignore the 2nd case, I assume you agree it is also correct.
And the 3rd case is one which is readily used, so claiming it's not true
is futile.
Consider:
find /var/spool/ordersys/closed -type f -mnewer /usr/ordersys/lastbkup
| cpio -o -Hcrc |
gzip -8 | growisofs -Z /dev/dvd=/proc/self/fd/0
How do I use cdrecord in this situation? The size of the data is not
known, and each run may or may not include the same files. Obviously the
size of the individual files doesn't change, each run is static, but run
to run isn't.
So if you can't know the exact size of the image before you start, you
can't burn from a pipe. Actually, I don't think you can burn at all with
dynamic data, there are old posts here indicating that even using the
builtin mkisofs, if the files are growing there can be problems. The
final size can be on the command line or in the ISO image, but must be
known at the start of the burn. See the man page "isosize" and "tsize="
descriptions. The latter explains that cdrecord uses modes which require
the information early.
It seems that you are uninformed - sorry but growisofs uses mkisofs!
No, it does not use mkisofs when reading from a pipe. It write the
incoming data to the media directly, and it need not be an ISO image at all.
Mkisofs is definitely not designed to work on a dataset that changes while
mkisofs is running.
Other than my mention that I expected problems, mkisofs is not
mentioned. The issue is that cdrecord with not read pipes and burn media
unless the size of the data is known in advance. This is the only issue
related to the three limitations I noted above.
Whether you _believe_ that you have been able to write something useful with
growisofs, while the dataset mkisofs is working on changes, is irrelevent.
In most cases, the resulting DVD will be just unusable or mkisofs will even
_abort_ because a file did change it's size between the creation of the
metadata part of it's output and the time when reading of the related file.
Repeat after me, "ISO images created by mkisofs are not the only data
you can burn to a DVD."
CONCLUSION: growisofs _may_ in some rare cases be able to create you a
usable DVD, but this is nothing you may rely on. Growisofs cannot give
you more than cdrecord gives you with pipes.
Irrelevant.
BTW: because it is a well known problem to make backups from life filessystems,
modern Operating Systems did develop filesystem snapshots. If you use snapshots,
there are no problems with _both_ growisofs _and_ cdrecord and this is the only
_reliable_ way to use pipes with mkisofs on life filesystems.
As long as a consistent dataset is written to the pipe with every run,
filesystem snapshots are irrelevant. Most database applications can
write a consistent dataset, not limited to just database programs like
Oracle, mysql, etc.
If you do not run a modern OS and thus lack snapshots, I recommend you to
upgrade to a modern OS that supports snapshots. Both Solaris and FreeBSD
support filesystem shapshots since ~ Y2000.
See above, o/s level snapshots are not needed for database, and may
actually freeze the data in the database in an inconsistent state.
The only other reliable way to do streaming backups from filesystems is to use
the method from the time _before_ filesystem snapshots have been introduced:
- Bring you computer down to single user mode
- Make the backup from a now stable filesystem
- Bring the system back to multi-user mode
If you are on an older OS and cannot upgrade to a recent OS, this is the only
way you may do backups.
Actually, as long as the backup dataset is consistent, I don't see that
the method of ensuring consistency is relevant. Some are more convenient
that other, I freely agree!
Jörg
--
E. Robert Bogusta
It seemed like a good idea at the time
Reply to: