Date: Sat, 25 Nov 2017 23:01:59 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: Diane Bruce <db@db.net>, "A. Wilcox" <AWilcox@Wilcox-Tech.com>, freebsd-arch@freebsd.org Subject: Re: The future of fortune(6) Message-ID: <20171125221422.N1628@besplex.bde.org> In-Reply-To: <201711242104.vAOL445P097106@pdx.rh.CN85.dnsmgr.net> References: <201711242104.vAOL445P097106@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Nov 2017, Rodney W. Grimes wrote: >> On Fri, Nov 24, 2017 at 02:40:42PM -0600, A. Wilcox wrote: >>> On 24/11/17 13:19, Adrian Chadd wrote: >>>> Pardon me, but it's 2017 and the 4.3BSD system index isn't an immutable bible. >>> This, so much this. Why is it so controversial to put the thing in a >>> package? Why do people want so badly to just remove it? Why wasn't it >>> discussed about putting it in a package? >> >> Let's bring back badblocks too while we are at it. > > Its badsect(8) and it has valid uses, even today. You can get ufs/ffs > drives that develope a bad block, you can fix the immediate issue with > badsect and a fsck, you loose a file. bad144(8) was removed earlier. You can also have old media with bad blocks, and might have used bad144 or badsect to hide them. The bad144 hiding method is fragile and no longer works. Sectors hidden using badsect remain hidden as well as before. They still cause long timeouts for copying the media, which is the easiest way to preserve it all. I don't know of any good way of preventing tree walks from accessing badsect files. badsect files have mode 0, but this doesn't prevent root reading them. ACLs can prevent root reading files but are not always available. File flags could prevent root reading files, but this is not implemented. > I have a 500G drive that has a spot that gets an error, smart flags > it as a pending relocation sector, when I back up and wipe the drive > to clear the pending hoping it well relocate it the drive decides hey, > I wrote and now read back that data so it is not bad, so puts it back > in the good sectors. Repeat a few times and you quickly learn to use > badsect t just map that sector out and let UFS never use it again. You can do the same manually using something like: - write zeros to other files until the disk is full - delete large files with bad blocks - wite zeros to small files until the disk is full - find the files with bad blocks in them (this is easier than using badsect, by observing the write errors for the previous step. Other steps are also easy, but take too long) - move the files with bad sectors in them out of the way and chmod them to 0 and make them immutable and set other flags for them (badsect never caught up with file flags). badsect just allows this to be done more easily. A script doing the above would be hard to make robust, and still take too long. Perhaps it can also be done using fsdb. The script to do that would be even harder to make robust. fsdb can probably do this even better by making the directory entries or inodes for the files inaccessble (I don't know how to do this without fsck wanting to fix it). > Now I have this ufs drive... if I stick it on a 12.x current system > it is probalby not gona like my badsect(8) that I have done and I > am unclear as what may happen. No, badsect files are normal after you run fsck on them. badsect+fsck is just a hack for getting bad sectors allocated where you want them. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171125221422.N1628>