[TAG] Re: CD/RW's on Fedora Core 3
Brian Bilbrey
bilbrey at orbdesigns.com
Sat Mar 5 18:49:38 MSK 2005
TAG - this is a re-addressed answer to a question about Linux CDRW/DVDRW
packet writing - I handn't tried to achieve that in a couple of years,
and found success this time around. Might be worth posting:
***
I think what you're looking for, if Google's been letting you down, is
CD R/W packet writing, so that a CD R/W drive can emulate a rw mounted
hard disc partition? Is my asssumption correct?
The area of interest is in a technology called Mount Rainier. I've not
used it, let's see what I can learn in a short span of time. Bear in
mind, I'm using Debian Sid (unstable), not Fedora. So I might look for
something more specific for you if I learn anything interesting.
First off, there's Mount Rainier technology, there's packet writing
tools, there's the udf file system ... after a bit of revisionist
Googling, I found that the right choice was to install udftools:
vimes:~# apt-get install udftools
Then I configured the contents of /etc/default/udftools, and rebooted.
Among other messages in my dmesg:
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe at suse.de) and petero2 at telia.com
cdrom: This disc doesn't have any tracks I recognize!
pktcdvd: writer pktcdvd0 mapped to hdc
That looks promising. Then I check if that pulled in the udf filesystem
kernel module... it didn't, so
vimes:~# modprobe udf
vimes:~# lsmod | grep udf
udf 92612 0
There's a mkudffs manpage, and one for pktsetup, too.
The pktsetup manpage has a useful little example sequence of using
packetwriting, so let me give this a try (first I'll pop in a DVD-R/W):
vimes:~# mkudffs /dev/pktcdvd/0
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=2077645, type=PSPACE
start=2077919, blocks=1, type=ANCHOR
start=2077920, blocks=239, type=USPACE
start=2078159, blocks=16, type=RVDS
start=2078175, blocks=1, type=ANCHOR
vimes:~# mount -t udf /dev/pktcdvd/0 /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/pktcdvd/0 4.0G 262K 4.0G 1% /mnt
vimes:~# mount | grep udf
/dev/pktcdvd/0 on /mnt type udf (rw)
vimes:/home/bilbrey/*/ISO# cp xandros-301-ocd-installation.iso /mnt
# time passes, small animals die
vimes:/home/bilbrey/downloads/ISO# ls -al /mnt
total 655839
drwxr-xr-x 3 root root 164 Mar 4 19:11 .
drwxr-xr-x 22 root root 648 Feb 6 15:48 ..
drwxr-xr-x 2 root root 40 Mar 4 19:11 lost+found
-rw-r--r-- 1 root root 671578112 Mar 4 20:17
xandros-301-ocd-installation.iso
vimes:/home/bilbrey/downloads/ISO# df -k /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/pktcdvd/0 4155290 656102 3499188 16% /mnt
This kept writing for a fair bit of time. Don't unmount until done, best
to sync first:
vimes:/home/bilbrey/downloads/ISO# sync
vimes:/home/bilbrey/downloads/ISO# umount /mnt
vimes:/home/bilbrey/downloads/ISO# eject
Now let's try with a cd rewriteable:
mkudffs fails with odd messages about extents. A small bit of searching
brought me to the cdrwtool utility. I've read the manpage, now I can use it:
vimes:~# cdrwtool -t 24 -d /dev/hdc -q
setting speed to 24
using device /dev/hdc
1312KB internal buffer
setting write speed to 24x
Settings for /dev/hdc:
Fixed packets, size 32
Mode-2 disc
I'm going to do a quick setup of /dev/hdc. The disc is going to be
blanked and formatted with one big track. All data on the device will be
lost!! Press CTRL-C to cancel now.
ENTER to continue.
Initiating quick disc blank
Disc capacity is 273824 blocks (547648KB/534MB)
Formatting track
# ! # ! # ! IMPORTANT # ! # ! # !
"Formatting track" step takes an inordinate amount of time. We're
talking up to an hour, according to some accounts. Even setting the
speed to something reasonable as I did up there doesn't make a lick of
difference. Personally, I bailed out on the first run, ended up
rebooting to get control of the drive back. Then I restarted using the
above command and searched while it ran. The process shows as D for
defunct. That would also be a lie, it's just hung while the write
finishes in it's own good time. It took about 25 minutes on my system,
then finished up like this. PATIENCE IS A VIRTUE.
# ! # ! # !
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=31, type=USPACE
start=288, blocks=32, type=PVDS
start=320, blocks=32, type=LVID
start=352, blocks=32, type=STABLE
start=384, blocks=1024, type=SSPACE
start=1408, blocks=272128, type=PSPACE
start=273536, blocks=31, type=USPACE
start=273567, blocks=1, type=ANCHOR
start=273568, blocks=160, type=USPACE
start=273728, blocks=32, type=STABLE
start=273760, blocks=32, type=RVDS
start=273792, blocks=31, type=USPACE
start=273823, blocks=1, type=ANCHOR
Writing UDF structures to disc
Quick setup complete!
No, the humour of "Quick setup complete!" is not lost on me.
Now, with the cdrw theoretically prepped with a udf filesystem:
vimes:~# mount -t udf /dev/pktcdvd/0 /mnt -o rw,noatime
vimes:~# df -k /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/pktcdvd/0 544256 42 544214 1% /mnt
vimes:~# mount | grep udf
/dev/pktcdvd/0 on /mnt type udf (rw,noatime)
Note that I added "noatime" to explicit mount options. When I read that,
it made great sense to me. Why write time of access to a slow filesystem
with horrid overheads?
vimes:/usr/src# cp kernel-source-2.6.10.tar.bz2 /mnt/.
vimes:/usr/src# sync
vimes:/usr/src# umount /mnt
vimes:/usr/src# eject
Both the DVD and the CD were readable on SWMBO's Windows XP box.
Lessons learned in summary:
For CDRW: use cdrwtool to format, and BE PATIENT
For DVDRW: use mkudffs to format
The real answer: If you can scrape up a eighty bucks, get a NEC 35XX
DVD+R/W drive. I've a 3500A, they're now on the 3520 series. Use DVD-R
and DVD-R/W for your normal data needs. Use CD-RW with cdrecord for
burning distro of the week. Use DVD-R/W for UDF fun. More data, less
patience. Joy all around.
You need kernel 2.6.8 or later to have the packet writing capabilities
in place in a stock kernel. Otherwise, you'll have to patch and build
your own. In which case, why not use 2.6.8 or later (I'm using
2.6.10-blah from Debian SID).
You need udftools.
It works. Now, does it work in FC3 ???? I have no idea. I'm pretty sure
that FC3's kernel is capable, I think it's pretty recent. Is it? Are
udftools present? If cdrwtool, mkudffs and pktsetup are there, then you
just need to read manpages and get the ball rolling. If not, you've some
doityourself work in front of you.
Hope this helps!
Good luck!
--
Brian Bilbrey : http://www.orbdesigns.com/
"Kirk to Enterprise -- beam down yeoman Rand and a six-pack."
More information about the TAG
mailing list