Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5

• Previous message: Yann Golanski: "Logitech UltraX mouse problem"
• In reply to: Zoltan Frombach: "kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5"
• Next in thread: Uwe Doering: "Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5"
• Reply: Uwe Doering: "Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 29 Apr 2005 14:13:25 +0200 (CEST)
To: freebsd-stable@FreeBSD.ORG, tssajo@hotmail.com

Zoltan Frombach <tssajo@hotmail.com> wrote:
> Apr 29 02:10:14 www kernel: swap_pager: indefinite wait buffer: device:
> ad0s1a, blkno: 328636, size: 8192
> Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device:
> ad0s1e, blkno: 329842, size: 4096
> [...]

The error message indicates that there was an I/O error
accessing the swap area on your disk. Usually that's an
indication for a hardware failure, e.g. a dying disk.

> I happen to have an identical hard drive around here, unused. If I hook it
> up as a slave (IDE) drive, is there a way I can mirror the dying drive to
> the spare one (with all partitions, etc, intact)?

If they're really identical (i.e. the same size and same
geometry), then you can use dd(1) for duplication, like
this:

# dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync

The "noerror,sync" part is important so the dd command will
not stop when it hits any bad spots on the source drive and
instead will fill the blocks with zeroes on the destination
drive. Since it's only the swap partition, you shouldn't
lose any data.

However, one disadvantage of dd is that it copies the drive
on block level, which means that it will also copy empty
blocks which aren't used at all. Neither does it make
sense to copy the swap partition.

If the filesystems on that drive don't contain much data,
it might be mor efficient to copy the data on filesystem
level. To do that, copy just the boot sector and disklabel
(using dd(1) to copy the first 64k or something should be
sufficient), then newfs the filesystems, mount them and
copy the contents with an appropriate tool. I recommend
"cpdup" from the port collection, because it's fast and
easy to use, but cpio should work as well (and it's in the
base of pretty much every UNIX system).

Performing newfs + filesystem copy also has the advantage
that you're starting with fresh, unfragmented filesystems,
and it gives you the opportunity to finetune the parameters
if necessary, such as the inode density (newfs -i).

> Any help/comments would be appreciated. Please CC me, as I am not a
> subscriber of this list. Thanks!!!

In that case you should set the "Reply-To" header in your
mail appropriately.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"In My Egoistical Opinion, most people's C programs should be indented
six feet downward and covered with dirt."
        -- Blair P. Houghton
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

• Previous message: Yann Golanski: "Logitech UltraX mouse problem"
• In reply to: Zoltan Frombach: "kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5"
• Next in thread: Uwe Doering: "Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5"
• Reply: Uwe Doering: "Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]