On Fri, Oct 19, 2001 at 10:26:51AM +1000, Andrew Smith <[EMAIL PROTECTED]> wrote:
| > On Thu, Oct 18, 2001 at 03:02:00PM -0500, Steve Snyder
| > <[EMAIL PROTECTED]> wrote:
| > | I'm playing with an external, SCSI-based DVD-RAM drive (a Hitachi
| > | GF-2050, marketed by Fantom). I've got a few questions regarding
| > | Linux support for | DVD-RAM:
| > |
| > | 1. I assume Linux supports read-only access of a DVD-RAM drive, but
| > | which filesystem should be used to access the device?
| > |
| > | 2. Does Linux support write access to DVD-RAM devices? If so, can
| > | someone point me to a HOW-TO?
| >
| > It's just an ordinary removable disc. I run ext2 with the noatime
| > option (to reduce writes to the disc - DVD-RAM is not fast).
|
| Hmm, Cameron, do you only use it for backup, or do you allow regular
| filesystem use of the drive?
Well, really just backup or moving data around (home to work type moves).
This is mostly because it's too physically slow for "normal" fs use. I
_treat_ it like a normal fs (the backups are don't by rsyncing to
the drive).
| I'm wondering because I imagine any use of RAM drive devices (CD or DVD -
| I have both - but don't use the RAM side of the 2 DVD drives I have)
| as standard filesystems would mean the discs would be throw away material
| VERY quickly unless you used a UDF filesystem - otherwise the high hit
| blocks (directories and filesystem specific blocks) would exceed the 1400
| rewrites (or whatever the limit is on your media) VERY quickly?
| e.g you copy 30 files to a directory - you *can* update the directory block
| 30 times
| I would expect you have considered this - but could you give us a run down
| of your decision to use ext2?
I hadn't really considered it because I hadn't realised the rewrite
limit was so low; I had it in the back of my mind but thought I had
less to fear. That said, my backups are not very frequent (weekly or
monthly, erraticly; I have some more redundancy in my system for most
stuff anyway). So ext2 was the easy choice, being in stock kernels.
| Is there a UDF filesystem that you can just put in fstab?
If you build a kernel for it, yes. When I was starting with this a few
years ago UDF write was very incomplete and buggy, and since I wasn't
writing video or data for others to use I felt no great need for it.
| (I am assuming that UDF was designed well - I have never looked into it)
That would be more an artifact of the implementation that the fs design,
which is in principle no more than a data format. I suspect that unless
you're in packet mode the behaviour is a bit like any other fs.
I have no idea how vigourously it rewrites the metadata; Ben Fennema
<[EMAIL PROTECTED]> is the guy to ask. Start here:
http://sourceforge.net/projects/linux-udf/
I do plan on playing with writing video sometime, and to that end have UDF
write built into my current kernel. But as yet no time!
It would be nice to have a mount option to say "really really don't care
about fs integrity - cache things as long as possible before commiting
to disc, yea even unto commiting to swap in preference to the fs media
itself" for media like DVD-RAM which are 1) arguably scratch in some
senses and uses and 2) have limited rewrite ability. Then you could
hammer on it to your heart's content and subject to available resources,
put off the physical writes until unmount time.
Of course, the other way to do that would be to dd the medium to a
big file on your hard drive, mount it in loopback mode, play with it,
then umount and rsync the big file back to the raw medium in checksum
mode. That would guarrentee minimum physicical writes. the downside
is that it takes a LONG time to read the whole medium in and to do the
compare on the way back out. What one really wants is a copy-on-write
image of the drive. Hmm. That's be way cool for several things.
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
When it gets down to the nitty-gritty of making your bike run well at a
particular place and time, the owner's manual may not be very helpful.
- Carl Shipman, "Motorcycle Tuning for Performance" 1973 2nd ed.
_______________________________________________
Seawolf-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/seawolf-list
