From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <71ed15d151980331661063c9918daaeb@collyer.net> From: Geoff Collyer To: 9fans@collyer.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] jukebox configuration changes Date: Fri, 1 Nov 2002 01:43:59 -0800 Topicbox-Message-UUID: 135463ac-eacb-11e9-9e20-41e7f4b1d025 I've just modified the file server kernel to cope with different DSIZEs (optical disc sizes) per jukebox and even per disc. It's now also possible to change FIXEDSIZES in /sys/src/fs/*/9*.c rather than having to edit dev/juke.c before compiling each distinct kernel. The way it used to work was that DSIZE was the size in RBUFSIZE-byte blocks of each optical disc *side*. However, it is possible to use discs of different sizes within a single jukebox: you set FIXEDSIZES to 0 and pay with a delay at each boot while the file server pulls each disc side in and asks the drive how big it is. It's probably wiser to use discs of the same size and set FIXEDSIZES to 1, which makes the file server just look at one disc and assume that all the sides are the size of its. So DSIZE was only used for computing the statistics that "statw" prints on the console, for working out sizes in the cache save and restore commands, and in the implementation of "check touch". Those operations could be led astray if DSIZE wasn't the size in Plan 9 blocks of all the optical discs in all jukeboxes on a given file server. If one wanted to put a jukebox with 5.2GB discs and one with 2.6GB discs on the same file server, it wouldn't work perfectly. DSIZE is gone. It's now possible to mix jukeboxes with discs of different sizes, and even, if you're willing to put up with the delays, to use discs of different sizes within a single jukebox, and everything should now work right. The whole thing compiles but I want to test it tomorrow (after the third jukebox arrives) before I offer the code to anyone else.