Re: DVD-RAM slowness and questions
From: Dances With Crows (danSPANceswitTRAPhcrows_at_gmail.com)
Date: 01/28/05
- Next message: mjt: "Re: Help: Suse Linux won't boot!"
- Previous message: Michael Heiming: "Re: Help: Suse Linux won't boot!"
- In reply to: Chris Carlen: "Re: DVD-RAM slowness and questions"
- Next in thread: zentara_at_highstream.net: "Re: DVD-RAM slowness and questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 28 Jan 2005 20:51:21 GMT
On Fri, 28 Jan 2005 11:19:19 -0800, Chris Carlen staggered into the
Black Sun and said:
> Dances With Crows wrote:
>> 2005 09:14:53 -0800, Chris Carlen staggered into the Black Sun and
>> said:
>>>I am experimenting with a 3x DVD-RAM cartridge in a Panasonic
>>>SW-9573C drive. I formatted with mke2fs -j. I have it mounted with
>>>the sync option.
>> ? If you mount a filesystem synchronously, it typically gets *slow*
>> because writes/reads can't take advantage of the buffer cache.
> Perhaps it isn't necessary. It's nice when manually entering
> commands, to know when it's done writing to the disk.
Huh? You need to umount the medium before ejecting it anyway, and
umount will wait for all pending writes to finish before returning.
> This is obvious when burning ISOs to CD/DVD media, but with this type
> of disk, not so obvious.
cdrecord/cdrdao work in a totally different way. They write directly to
the SCSI generic device, and they don't mount the medium, so there's no
buffer caching going on anyway.
>> Journalling is not going to be very useful on a removable medium.
>> Any journalling FS will be slower than a non-journalling FS
> I have recently had a Reiserfs formatted hard drive fail, but almost
> all files were recovered with their original names. Only the
> directory structure was shattered, and a few files trashed. Would
> this level of recovery, let's say 90%, have been more or less likely
> with a non-journaling filesystem such as ext2 or FAT?
Impossible to say, because every hardware failure is different. I think
you've got the wrong idea about journalling, though. Journalling does
*not* guarantee data recovery in the event of a hardware failure. (You
need RAID-{1,5,0+1} for that.) Journalling merely makes it so that the
filesystem is almost always in a consistent state. That means you can
use the filesystem in seconds after a power failure (journal replay
takes seconds) instead of waiting {minutes,hours} for fsck to finish.
> Also, the question remains, is there an optimum set of parameters for
> an ext2/3 filesystem to give the best performance on a DVD-RAM?
Dunno. If the sector size for DVD-RAM is 2048, -b 2048 may provide
improvements. Or not.
>> DVD-RAM, you should probably use a lowest-common-denominator
>> filesystem like FAT32,
> I have considered this. I think in this case since I will be backing
> up mainly a Linux home dir, that a Linux-only filesystem is OK.
> mango2:/media # mkdosfs -F32 -I /dev/dvdram
> mkdosfs: unable to get drive geometry for '/dev/dvdram'
Great. Well, if you only use it for backup, ext[23] will probably work.
>>>Also, I have heard that DVD-RAM verifies itself.
>> What? Don't paraphrase things.
> What I meant was I have understood from reading technical discussions
> of various levels (including the DVD-RAM standard ECMA-272 which I
> only understand enough to know it's very complicated), that the
> DVD-RAM is capable of some sort of *low-level* on the fly
> verification, such as at the sector level. This would thus require
> "someone" to read back the data written, and to do something about it
> if there are errors. Such a low-level verification would be
> transparent to the user, as I have understood it. Thus, it might also
> require that there be a maintenance of a bad sector list or something
> like that on the disk.
>
> Who does this? The drive or the driver?
The drive. Similar things are done with modern IDE/SCSI disks, though
it's called "transparent bad-sector remapping" there.
> Is what I have gathered even approximately correct?
I don't know for sure, since I haven't read the technical standard for
DVD-RAM. It sounds like it's feasible though.
> that there is low-level verification capability, and that it is a
> driver responsibility, then how do I know if Linux is doing it?
This is done on the drive's logic board if it's done anywhere. The only
time you'll see anything is if it fails, when you should see the drive
reporting an error to the kernel, and then you'll see a cryptic-looking
error from device XX:YY in the output from dmesg.
> does Linux think the DVD-RAM is? A plain old hard drive? What is the
> driver involved? Just the IDE/ATAPI?
SCSI under ide-scsi emulation, unless you're running a newer 2.6 kernel.
The device looks like a removable-media disk (think "large ZIP drive")
and is treated like one.
-- Matt G|There is no Darkness in Eternity/But only Light too dim for us to see Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong http://www.brainbench.com / Hire me! -----------------------------/ http://crow202.dyndns.org/~mhgraham/resume
- Next message: mjt: "Re: Help: Suse Linux won't boot!"
- Previous message: Michael Heiming: "Re: Help: Suse Linux won't boot!"
- In reply to: Chris Carlen: "Re: DVD-RAM slowness and questions"
- Next in thread: zentara_at_highstream.net: "Re: DVD-RAM slowness and questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
