Re: Linux kernel 2.6.x Raw device support
Hi,
> For my own history I have been using tar output piped to sdd to be directly
> written using the raw device drivers for about 3 years now I think on many
> servers. This use requires a kernel patch available from Andy for 2.4
> series kernels and 2.6 series kernels have not required a patch.
That explains why i never was aware of a generally
DVD+RW device file. From time to time i read some
rumors but always ended up at Andy's patch (which is
obsolete if you can restrict yourself to sequential
streams and use growisofs) or at udf-tools which
seem to need a 2.4-kernel patch too. Their writing
method seems to use raw devices and offer access
to CD-RW and DVD+RW.
Naively one would expect that there are CD- and DVD-
devices in an OS like there are devices for disks
and tapes and whatever strange hardware.
Somehow this idea did never really succeed in reality. :(
> If I
> recall from when Andy added this feature I think the operation is
> independent of the structure of the incoming data so I think it should
> work for my purposes.
Yes. For me it works with ISO9600 or afio format as well as
with permuted and multiplied images.
So one can say that it accepts any stream. I encountered the
neglible problem that it interprets eventual ISO filessytem
headers and prints misleading progress information in case that
further data are appended to the ISO image. (In my case checksum
information or further copies of the image)
It also seems not always to exit with an error indicating
value on failure.
Another thing is that you need a file object that delivers
the standard input of the process (/proc/self/fd/0 or
/dev/fd/0 on my Linux) if you generate the data stream
on the fly.
> For data backup purposes, it makes no sense to use the
> additional overhead and file handling to format an ISO image unless it is
> intended to be read from another OS platform that does not have a direct
> capability like in Windows.
ISO trees have advantages in case of smaller data mishaps.
For example the files are accessible by arbitrary clicky-colorful
filemanagers. (Very important for KDE users :))
ISO also allows to test backuped files with their original
application programs. (Very important feature to soothe
the scruples of people who already suffered from unreadable
DAT tapes or similar backup bloops.)
On the other hand the pitfalls of ISO (and in part of mkisofs)
cannot be ignored when it comes to backups of non-data files,
deep trees, wide trees, to preservation of access permissions,
or error recovery with damaged media.
On a backup area with completely arbitrary file objects i use
the traditional archiver afio. It serves me since the days of
DC-6150 tapes.
Have a nice day :)
Thomas
Reply to: