I'd like to know if fsck would serve as an alternative to Spinrite or HDD Regenerator.

Will fsck mark bad physical sectors, and write the partition table to ensure they are never allocated?

Well, technically, fsck is just a front-end to the various file system specific checkers. Use the info fsck command from a terminal window for details.

In general, no, fsck invoked checkers will not change the partition information. Depending on the file system is use, a "bad inode" table may be accessed to "black list" physical locations on the disk, but this is not added to the disk partition information.

Note that most IDE or SATA drives produced since the eighth decade of the 20th century have included "self repair" hardware, and un-allocated sectors, which are automatically used to replace any sectors found to be bad when the drive's POST is run. And, I think, periodically thereafter. So, unless you're using a really old drive, I'd suspect that the functionality you're considering is, at best, obsolescent.

As I understand it, those drive analysis/repair tools go deeper than fsck, which IFAIK only looks at the filesystem data, not the lower level drive information. That's not to say spinrite and friends don't know about the filesystem data too.

I think those deeper tools do lots of funky stuff, among it using SMART, which is something to do with asking the drive about lower level stuff. There is a SMART daemon which runs on Linux which I think is used to monitor the health of drives, but I don't know exactly what it is capable of.

In my particular case, I have an old Seagate ST3491A, which was manufactured in a time before they printed dates of manufacture on the drives . I've noticed data corruption that fsck does not correct (ie. fsck finds errors everytime it runs, even when it runs two passes back to back). This suggests that fsck does no kind of preventative maintenance. I would also speculate that this drive predates SMART features, so software that merely makes use of SMART would probably be inadequite. In cases where a drive doesn't have SMART, Spinrite appears to bridge the gap by implementing it's own version of it; at least, that's what the marketing propaganda leads me to think. So my next question is whether there exists a GNU package that's as extensive as spinrite.

If you end up buying SpitRite, I'd be interested to find out if it works, or if the [plausible sounding] user feedback which gets read out on Security Now is accurate...

From what I've been reading, you're correct. Although GRC states that Spinrite is purely concerned with low level physical aspects, and knows nothing about filesystems. However I'm not sure how GRC can make that statement, when their software was claimed at one point to only work on FAT16 filesystems.

I'm curious where the bad block blacklist is stored. What if Spinrite marks some areas as bad, and then I wipe out the HDD after that and start over? Is the blacklist lost?

I've also read that ddrescue is the GNU alternative to Spinrite, but I got the impression ddrescue is purely for data recovery, and doesn't attempt to restore the HDD back to use by marking bad areas.

From the first line of the DESCRIPTION section of "man fsck":
You did tell it to actually repair things and not just report them, right? Just making sure...

I don't recall. Hopefully I used the -a switch. I remember that it ran as part of the bootup process, and said something to the effect that it was unable to repair and that I should run fsck manually. When I ran fsck, I recall it complained that the drive was readonly (the boot sequence probably rendered it readonly when problems were found). So I had to remount the drive as read/write so I could run fsck. I assume fsck would not require a writeable filesystem if it wasn't set to repair.

I thought I just posted, but it didnt show up. So it it shows up later and this is a duplicate ... sorry about that!
Normally you run fsck on an unmounted filesystem. It can be dangerous to run it on a mounted one!

Maybe I misused the tool then. I don't think it would have mattered anyway; since Spinrite found some physically defective areas.