Re: what to do about "cannot dump to dumpdev hd(1/41): space for



Steve M. Fabac, Jr. wrote:

If there is an unreadable track in the swap space, it should become apparent
by just using "dd if=/dev/part1 of=/dev/null bs=63b" from the booted system
on the IDE disk. Dd does not care what is in the file system and if a
bad block is encountered, it will be displayed on the system consol and
logged to /usr/adm/syslog. The 63b is taken from hwconfig -h for the
hard disk showing 255 hds, 63 sectors.

Assuming that your opening statement is valid, and
just picking numbers at random: If the the swap was

| swap | NON FS | no | 1 | 30722| 816753|


I'd change it to:

| swap | NON FS | no | 1 | 430722| 816753|

Dropping approximately 50% of the swap space from the beginning of
its original range then try to boot the disk.

We are not trying to get the system to run with only 50% of its original
swap space. Just trying to prevent a kernel panic if their is a unreadable
track at or near the beginning of the swap space.

I'm pretty sure that OSR5 neither writes nor reads a single sector
to/from the swap device until (a) it starts swapping or (b) it tries to
write a panic dump. If a panic reports 0 blocks of dump space, this
means that dumpdev was set to a nonsensical value (a major/minor number
that isn't even a disk); or, most likely, points to a partition or
division slot number which hasn't been created. That is, if the disk
has two partitions and dumpdev is pointing to the third (nonexistent)
partition.

The default value of swapdev & dumpdev is 1,41, i.e. "first drive unit
of 'hd' driver, active partition, division #1" (and 'hd' driver is
hooked to "wd" == IDE if there are any IDE hard disks in the system,
else SCSI. Or IDA or PS/2 ESDI or PS/2 ST506 or a few other even more
obscure drivers, none of which are in play...) Even if an active
partition exists on drive 0, if its division #1 slot is empty, you'll
get that message.

It's impossible for the dump device to be "full" of old dumps. Each
kernel dump starts at the beginning of the dump device and overwrites
what's already there.

If dumpdev is smaller than needed by the dump, the dump aborts before
writing anything (even if it's only 1K short). The message in that case
would be a pretty obvious "Cannot dump 65536 pages to dumpdev hd (1/41):
Space for only 65535 pages".

However, one big stumbling block is the OP's inability to accurately identify
the swap division. Changing the starting block of a valid file system
by mistake would likely be disastrous. Fsck -n /dev/part0, ...part1, ...part2,
etc., should identify valid file systems. when he hits the swap it should
be similar to running fsck -n /dev/swap:

# fsck /dev/swap
fsck: cannot determine filesystem type of /dev/swap.

Don't do that. Your text says "fsck -n" but your example shows just
"fsck". If it does detect /dev/swap as some sort of filesystem, who
knows what it's going to do.

But most of all, don't do that because:

# dtype /dev/swap
# fstyp /dev/swap

are better and safer ways of doing it.

===

Nobody has addressed the subtext of the original poster's issue. If
it's saying "Cannot dump to dumpdev ...", it's doing that because the
system's panicking. Whether it can write a dump is an irrelevant
distraction. The important thing is, why is it panicking?

Before the "Cannot dump" message there should be some panic messages.
Post those. Try to duplicate every character exactly, precision is
important. Also describe how it gets there: does it panic every time at
bootup, randomly while the system's been up for a while, only when it's
under heavy load, only when printing to a printer, or what?

Bcc'd original poster in case he's not reading the news. Post response
to comp.unix.sco.misc.

Bela<
.



Relevant Pages

  • Re: Backing up FREEBSD
    ... Many people are now buying large extra disk drives just to contain ... less convenient for archival backups. ... You can easily write to either tape or disk with dump. ... things you want to back up are put in a particular partition (file system) ...
    (freebsd-questions)
  • Re: mdconfig unable to allocate memory
    ... > one ensure that all the memory is being used for suitable file caching ... > disk, really; I assumed that it would immediately start dumping ... > anything I put in it, into swap, causing disk access. ... file system with 4GB of RAM without a problem, ...
    (freebsd-current)
  • Re: what to do about "cannot dump to dumpdev hd(1/41): space for
    ... hard disk showing 255 hds, ... If a panic reports 0 blocks of dump space, ... Changing the starting block of a valid file system ... it panics in the exact same spot every time. ...
    (comp.unix.sco.misc)
  • Summary: Root cause of swap space full
    ... The only way I could see that this particular file system causing the ... w/ no disk mounted under it. ... I'm assuming that the filesystem you mention is a VxFS filesystem. ... can't think of any reason that filling it would cause a swap issue. ...
    (SunManagers)
  • Re: Choosing location for large temp files?
    ... There can be some interaction with the user to choose the swap file location, but the more the program can find out about it, the better. ... But, from a file-system coherence point of view, if we assume this is truly a temporary file, deleted when the application exits normally, then you may prefer to store the file in the user's own "Application Data" subdirectory somewhere, as long as that meets whatever other criteria you have. ... Wherever you put the file, you should be careful, of course, to provide features in your program to try to recover from errors that might have prevented the deletion of the temp file; otherwise, the disk could be consumed quickly. ... To give the file system the best chance to optimize how the file is stored on disk, you'll want to seek to the file's last extent when creating it so that the file system can know how large the file is going to be and can allocate space for it. ...
    (microsoft.public.dotnet.languages.csharp)