From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 7 Oct 2005 00:11:50 -0400 From: Russ Cox To: Thomas Miller , Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] fossil shutdown In-Reply-To: <4345f0bd.l5R330s/pBsD2tR1%tom@insolvencyhelp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <773c9e03fdb75bc23d88836c96abb42a@terzarima.net> <4345f0bd.l5R330s/pBsD2tR1%tom@insolvencyhelp.org> Cc: Topicbox-Message-UUID: 956de944-ead0-11e9-9d60-3106f5b1d025 > > echo dma on >/dev/sdXX/ctl > > echo rwm on >/dev/sdXX/ctl > Inspired, I tried this, and I got an improvement (decrease) > in time taken to copy files to a new filename of at least > an order of magnitude. > I was surprised to find the letters "rwm on" right at the > beginning of the disk. I saved the output of > I'm pretty sure that I did *not* type > > echo rwm on > /dev/sdC0/data /* WRONG */ I'm pretty sure that you did type echo dma on >/dev/sdC0/ctl echo rwm on >/dev/sdC0/data explaining both the performance improvement and the subsequently broken mbr. The disk fragment you posted on the ftp server begins with a standard NetBSD mbr except that the first 7 bytes are "rwm on\n". This is perfectly explained by a typo and very hard to explain with a software or hardware error. Once I set up a pseudo-worm file server on a few SCSI disks, spent a few hours populating it, and then rebooted and the kernel couldn't find the file system. On inspection, I found postscript code in what should have been the file server's superblock. That felt like a hardware error (shouldn't use discarded machines; people discard them for a reason!). This doesn't. Russ