From owner-freebsd-current Sun Nov 26 05:45:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA07480 for current-outgoing; Sun, 26 Nov 1995 05:45:47 -0800 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA07285 for ; Sun, 26 Nov 1995 05:43:24 -0800 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id PAA28905 for current@freebsd.org; Sun, 26 Nov 1995 15:46:46 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id PAA23326 for ; Sun, 26 Nov 1995 15:15:15 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id PAA20864; Sun, 26 Nov 1995 15:15:14 +0200 From: "Andrew V. Stesin" Message-Id: <199511261315.PAA20864@office.elvisti.kiev.ua> Subject: "Gold" writable CDs and FreeBSD -- opinions, comments? To: hardware@freebsd.org Date: Sun, 26 Nov 1995 15:15:13 +0200 (EET) Cc: current@freebsd.org X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 4990 Sender: owner-current@freebsd.org Precedence: bulk Hello people, especially famous SCSI, CDROM and filesystems experts! This message is pretty long, I strongly apologize for taking your time. Wouldn't you mind reading it and commenting my ideas a bit, please? I think, that may be interesting not only for me personally, and I really need your comments and opinions to help me to make a decision. I'd appreciate any feedback, including "rotten potatoes"... :-) Thanks in advanse! I know there are some devices with SCSI interfaces for doing massive backups with a great "bang-per-buck" -- namely WORMs and writable ("gold") CD drives. I even used a writable-CD device some time ago, it had some windo$e control utility. WORMs are rare today here, but writable-CD devices are present on the market. (BTW this is a considerable investment, not a simple $100, and each goldCD costs at least $15 here, so the reasons to buy it must be strong. They are strong for us there even without considering using it with FreeBSD, and a possibility of FreeBSD to work with this device will increase the strength even more). Using of writable "gold" CDs may be _very_ attractive. Not for backups first of all (for the reasons that you usually need to have a non-busy system to get writing process streaming without any interrupts in data transfer between a disk and a writable device, otherwise the goldCD will become damaged and unusable; so you need to go single-user to be sure your'e Ok, this isn't too convenient for everyday use. But nevertheless, you don't do such _massive_ backups every single day? once a week or two; it seems to be acceptable) Suppose you are creating a firewall router' custom configuration. You use some small old SCSI disk for a) booting the kernel, b) reading hand-tunable configuration from /etc, d) writing tempfiles & logs, maybe swapping if needed. Everything else, all daemons, utilities, will live on a hand-burned goldCD so even if the host itself is compromised via the net, an intruder will be _physically_ unable to leave any sugnificant hooks or Trojan horses in the system for later reuse, and me, poor admin, won't need to worry checking or reloading all the binary tree (even if comparatively small), especially assuming that the box may be very far from me and physically unaccessible. Some kind of super-smart hardware router with 650Mb of flash ROM but a LOT cheaper and useable I think :-) The same is true for any other, not only router, case when you want to be _totally_ sure that nobody and nothing will change your carefully customized and tuned configuration. Then, you get a possibility of making cheap series of copies of your solution. And even more: you get rid of any hard disk troubles or of any cases when actual admin of the system occasionally changes /bin/cat permissions to suid root, thus tech support is a lot easier. Opinions? I'm almost sure that people who sell FreeBSD solutions will agree with me at least for some points. What I want to ask is: suppose I get such a device (a drive for writing "gold" CDs, with SCSI interface). I'll be using it with windo$e from the very start, of course. But what steps are required to get it working with FreeBSD? I think there are: * ensure myself that it works nice in a usual RO CD mode. * get a description of it's command interface used to initiate, tune and perform writing. This may be difficult, though... But suppose for now that I've already got one. (?) Then a first dark spot comes up. What step will be the next? I think that I'd need to examine existing drivers for SCSI devices and to add some new functionality to a 'cd' driver, yeah? This includes lazer tuning, calibration, test-writing commands, "close record", etc. * So, good, now I take some simplistic CDplayer program without bells&whistles and make it work for writing. * suppose I got it working and writing a stream of blocks of needed length to a goldCD. Ok, we win! Comments? Or -- just another approach. Suppose I don't worry about support of CD write operations for the goldCD at all (I'd get a windo$e utility at last, damn it, but it works). I'm going to create a 650Mb file with ISO9660 FS inside it, write everything I want there, test it; then transfer the whole 650Mb file to the windo$e box and burn it into the goldCD there. Much less convenient in terms of disk usage, but is this possible at all just now? (I've hear rumors that writing is broken for ISO9660 FS). Another aproach. If ISO9660 is really broken for writing, can I create a "normal" Berkeley FFS filesystem in the file, burn it to the goldCD and mount it later? I don't care that windo$e won't read this disk, really! :) Anyway, will a mount command _without_ '-t cd9660' be possible for a CD? What caveats one can expect here? Thanks a lot for reading this and for your comments! -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error.