Re: gpart -b 34 versus gpart -b 1024

2010-07-25 Thread Edho P Arief 
On Sun, Jul 25, 2010 at 12:37 PM, Adam Vande More  wrote:
> On Sat, Jul 24, 2010 at 10:58 PM, Dan Langille  wrote:
>
>>       ---Sequential Output ---Sequential Input-- --Random--
>>       -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
>>    GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU  /sec %CPU
>>    50 110.5 81.0 112.8 15.0  62.8  9.0  72.9 48.5 139.7  9.5   144  0.9
>>
>> Here, the results aren't much better either...  am I not aligning this
>> partition correctly?  Missing something else?  Or... are they both 4K block
>> aligned?
>
>
> The alignment doesn't apply to all drives, just the 4k WD's and some ssd's.
>
> If they were misaligned, you would see a large difference in the tests.  A
> few points one way or other in these is largely meaningless.
>
> That being said, if I were you I would set -b 2048(1 MB) as the default, the
> amount of space wasted is trivial and your partition will always be
> aligned.  People following your tutorials may have a variety of different
> drives and that setting is safe for all.
>

shouldn't it start at 2049? Starting at 2048 means it starts at 2048th
logical block which is 512 bytes off from physical block, doesn't it?


-- 
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: gpart -b 34 versus gpart -b 1024

2010-07-25 Thread Adam Vande More 
On Sun, Jul 25, 2010 at 2:22 AM, Edho P Arief  wrote:

>
> shouldn't it start at 2049? Starting at 2048 means it starts at 2048th
> logical block which is 512 bytes off from physical block, doesn't it?
>  
>

blocks start at 0

-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: gpart -b 34 versus gpart -b 1024

2010-07-25 Thread Dmitry Morozovsky 
On Sun, 25 Jul 2010, Adam Vande More wrote:

AVM> >
AVM> > shouldn't it start at 2049? Starting at 2048 means it starts at 2048th
AVM> > logical block which is 512 bytes off from physical block, doesn't it?
AVM> >  
AVM> >
AVM> 
AVM> blocks start at 0

Well, to be exact, LBA starts at 0, while sector numbers (in CHS address 
method) at 1 (which always suprized me ;)

-- 
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SIGEPIPE after update to 8.1-RC2

2010-07-25 Thread Jilles Tjoelker 
On Sun, Jul 18, 2010 at 12:20:33PM +1000, Sean wrote:
> I'm getting the same thing; what shell are you using? I changed my shell 
> on one machine from /bin/tcsh to /usr/local/bin/bash and problem 
> disappeared.

That this workaround helps confirms that masked/ignored SIGPIPE is the
problem. From a few shells I have tried, bash and zsh reset SIGPIPE to
caught or default even if it was ignored (only in interactive mode,
however), while tcsh, sh, mksh and ksh93 leave it ignored.

The underlying problem is the program that is passing the ignored/masked
signal to child processes. Please check if the problem occurs with
various ways to log in (text console, ssh, xterm, etc). Things like PAM
modules may also cause problems here.

For example, sshd sets SIGPIPE to ignored, but resets it back to default
before starting a child process, so assuming I read the code correctly
it does not cause problems.

-- 
Jilles Tjoelker
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: no updates?

2010-07-25 Thread Beach Geek 
Did my last post get cut off?
Still getting used to this Andriod.

On Jul 21, 2010 3:13 PM, "Chip Camden"  wrote:

This is probably a stupid question, but I haven't received any csup
updates for a couple of days now, even though I've seen quite a few
commits on the list.  I'm using the cvs tag=RELENG_8

I've tried both cvsup4.freebsd.org and cvsup10.freebsd.org (my two
fastest connections).

Are the mirrors just having a hard time keeping up?  Or do I need to
change my configuration?  I'm using
/usr/share/examples/cvsup/standard-supfile, unmodified.  Just in case,
here's what it looks like:

# $FreeBSD: src/share/examples/cvsup/standard-supfile,v 1.25.4.2 2009/08/12
07:25:56 kensmith Exp $
#
# This file contains all of the "CVSup collections" that make up the
# FreeBSD-current source tree.
#
# CVSup (CVS Update Protocol) allows you to download the latest CVS
# tree (or any branch of development therefrom) to your system easily
# and efficiently (far more so than with sup, which CVSup is aimed
# at replacing).  If you're running CVSup interactively, and are
# currently using an X display server, you should run CVSup as follows
# to keep your CVS tree up-to-date:
#
#   cvsup standard-supfile
#
# If not running X, or invoking cvsup from a non-interactive script, then
# run it as follows:
#
#   cvsup -g -L 2 standard-supfile
#
# You may wish to change some of the settings in this file to better
# suit your system:
#
# host=CHANGE_THIS.FreeBSD.org
#   This specifies the server host which will supply the
#   file updates.  You must change it to one of the CVSup
#   mirror sites listed in the FreeBSD Handbook at
#   http://www.freebsd.org/doc/handbook/mirrors.html.
#   You can override this setting on the command line
#   with cvsup's "-h host" option.
#
# base=/var/db
#   This specifies the root where CVSup will store information
#   about the collections you have transferred to your system.
#   A setting of "/var/db" will generate this information in
#   /var/db/sup.  You can override the "base" setting on the
#   command line with cvsup's "-b base" option.  This directory
#   must exist in order to run CVSup.
#
# prefix=/usr
#   This specifies where to place the requested files.  A
#   setting of "/usr" will place all of the files requested
#   in "/usr/src" (e.g., "/usr/src/bin", "/usr/src/lib").
#   The prefix directory must exist in order to run CVSup.

# Defaults that apply to all the collections
#
# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/doc/handbook/mirrors.html.
*default host=CHANGE_THIS.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_8
*default delete use-rel-suffix

# If you seem to be limited by CPU rather than network or disk bandwidth,
try
# commenting out the following line.  (Normally, today's CPUs are fast
enough
# that you want to run compression.)
*default compress

## Main Source Tree.
#
# The easiest way to get the main source tree is to use the "src-all"
# mega-collection.  It includes all of the individual "src-*" collections.
src-all

# These are the individual collections that make up "src-all".  If you
# use these, be sure to comment out "src-all" above.
#src-base
#src-bin
#src-cddl
#src-contrib
#src-etc
#src-games
#src-gnu
#src-include
#src-kerberos5
#src-kerberosIV
#src-lib
#src-libexec
#src-release
#src-rescue
#src-sbin
#src-share
#src-sys
#src-tools
#src-usrbin
#src-usrsbin
# These are the individual collections that make up FreeBSD's crypto
# collection. They are no longer export-restricted and are a part of
# src-all
#src-crypto
#src-eBones
#src-secure
#src-sys-crypto

--
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com|
http://chipsquips.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: no updates?

2010-07-25 Thread Beach Geek 
Still no updates?
How are you running the update? (command line or cron or ?)
How are you specifying the host?  (-h or editing the *default host line)

On Jul 21, 2010 3:13 PM, "Chip Camden"  wrote:

This is probably a stupid question, but I haven't received any csup
updates for a couple of days now, even though I've seen quite a few
commits on the list.  I'm using the cvs tag=RELENG_8

I've tried both cvsup4.freebsd.org and cvsup10.freebsd.org (my two
fastest connections).

Are the mirrors just having a hard time keeping up?  Or do I need to
change my configuration?  I'm using
/usr/share/examples/cvsup/standard-supfile, unmodified.  Just in case,
here's what it looks like:

# $FreeBSD: src/share/examples/cvsup/standard-supfile,v 1.25.4.2 2009/08/12
07:25:56 kensmith Exp $
#
# This file contains all of the "CVSup collections" that make up the
# FreeBSD-current source tree.
#
# CVSup (CVS Update Protocol) allows you to download the latest CVS
# tree (or any branch of development therefrom) to your system easily
# and efficiently (far more so than with sup, which CVSup is aimed
# at replacing).  If you're running CVSup interactively, and are
# currently using an X display server, you should run CVSup as follows
# to keep your CVS tree up-to-date:
#
#   cvsup standard-supfile
#
# If not running X, or invoking cvsup from a non-interactive script, then
# run it as follows:
#
#   cvsup -g -L 2 standard-supfile
#
# You may wish to change some of the settings in this file to better
# suit your system:
#
# host=CHANGE_THIS.FreeBSD.org
#   This specifies the server host which will supply the
#   file updates.  You must change it to one of the CVSup
#   mirror sites listed in the FreeBSD Handbook at
#   http://www.freebsd.org/doc/handbook/mirrors.html.
#   You can override this setting on the command line
#   with cvsup's "-h host" option.
#
# base=/var/db
#   This specifies the root where CVSup will store information
#   about the collections you have transferred to your system.
#   A setting of "/var/db" will generate this information in
#   /var/db/sup.  You can override the "base" setting on the
#   command line with cvsup's "-b base" option.  This directory
#   must exist in order to run CVSup.
#
# prefix=/usr
#   This specifies where to place the requested files.  A
#   setting of "/usr" will place all of the files requested
#   in "/usr/src" (e.g., "/usr/src/bin", "/usr/src/lib").
#   The prefix directory must exist in order to run CVSup.

# Defaults that apply to all the collections
#
# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/doc/handbook/mirrors.html.
*default host=CHANGE_THIS.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_8
*default delete use-rel-suffix

# If you seem to be limited by CPU rather than network or disk bandwidth,
try
# commenting out the following line.  (Normally, today's CPUs are fast
enough
# that you want to run compression.)
*default compress

## Main Source Tree.
#
# The easiest way to get the main source tree is to use the "src-all"
# mega-collection.  It includes all of the individual "src-*" collections.
src-all

# These are the individual collections that make up "src-all".  If you
# use these, be sure to comment out "src-all" above.
#src-base
#src-bin
#src-cddl
#src-contrib
#src-etc
#src-games
#src-gnu
#src-include
#src-kerberos5
#src-kerberosIV
#src-lib
#src-libexec
#src-release
#src-rescue
#src-sbin
#src-share
#src-sys
#src-tools
#src-usrbin
#src-usrsbin
# These are the individual collections that make up FreeBSD's crypto
# collection. They are no longer export-restricted and are a part of
# src-all
#src-crypto
#src-eBones
#src-secure
#src-sys-crypto

--
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com|
http://chipsquips.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: no updates?

2010-07-25 Thread Jeremy Chadwick 
On Wed, Jul 21, 2010 at 01:13:01PM -0700, Chip Camden wrote:
> This is probably a stupid question, but I haven't received any csup
> updates for a couple of days now, even though I've seen quite a few
> commits on the list.  I'm using the cvs tag=RELENG_8
> 
> I've tried both cvsup4.freebsd.org and cvsup10.freebsd.org (my two
> fastest connections).
> 
> Are the mirrors just having a hard time keeping up?  Or do I need to
> change my configuration?

Your configuration looks fine -- given the hostname, I assume you're
using variables in /etc/make.conf (ex. SUPHOST) to define the cvsup
server's name and allow you to do "make update" in /usr/src and the
like.

The only thing I can think of is: when you installed FreeBSD, did you
choose to install ports and src?  If so, prior to running csup, did you
"adopt" your existing data?

http://www.cvsup.org/faq.html#caniadopt

If not, I imagine what's happened is that the contents of /usr/src don't
match what's in /var/db/sup/src-all.

If you don't want to bother with adoption, you can do the following (be
sure to back up your kernel configuration file first, unless you do what
I do and use a symlink :-) ) to start over completely:

rm -fr /usr/src/*
rm -fr /var/db/sup/src-all
csup -h {server} -L 2 /usr/share/examples/cvsup/stable-supfile

(Or standard-supfile, depending on what tag you want to follow)

For this reason I don't choose src or ports when installing FreeBSD.
I populate /usr/src and /usr/ports after the OS is installed, using
csup.  I've never had a single problem since.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: no updates?

2010-07-25 Thread Chip Camden 
Quoth Beach Geek on Sunday, 25 July 2010:
> Still no updates?
> How are you running the update? (command line or cron or ?)
> How are you specifying the host?  (-h or editing the *default host line)
> 
> On Jul 21, 2010 3:13 PM, "Chip Camden"  wrote:
> 
> This is probably a stupid question, but I haven't received any csup
> updates for a couple of days now, even though I've seen quite a few
> commits on the list.  I'm using the cvs tag=RELENG_8
> 
> I've tried both cvsup4.freebsd.org and cvsup10.freebsd.org (my two
> fastest connections).
> 
> Are the mirrors just having a hard time keeping up?  Or do I need to
> change my configuration?  I'm using
> /usr/share/examples/cvsup/standard-supfile, unmodified.  Just in case,
> here's what it looks like:
> 
> --
I should have replied sooner -- within a day of my post, cvsup4 caught
up.

-- 
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com


pgpVmgaMDvBCp.pgp
Description: PGP signature

zpool destroy causes panic

2010-07-25 Thread Dan Langille 
I'm trying to destroy a zfs array which I recently created.  It contains 
nothing of value.


# zpool status
  pool: storage
 state: ONLINE
status: One or more devices could not be used because the label is 
missing or

invalid.  Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-4J
 scrub: none requested
config:

NAME  STATE READ WRITE CKSUM
storage   ONLINE   0 0 0
  raidz2  ONLINE   0 0 0
gpt/disk01ONLINE   0 0 0
gpt/disk02ONLINE   0 0 0
gpt/disk03ONLINE   0 0 0
gpt/disk04ONLINE   0 0 0
gpt/disk05ONLINE   0 0 0
/tmp/sparsefile1.img  UNAVAIL  0 0 0  corrupted 
data
/tmp/sparsefile2.img  UNAVAIL  0 0 0  corrupted 
data


errors: No known data errors

Why sparse files?  See this post:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1007077+0+archive/2010/freebsd-stable/20100725.freebsd-stable

The two tmp files were created via:

dd if=/dev/zero of=/tmp/sparsefile1.img bs=1 count=0  oseek=1862g
dd if=/dev/zero of=/tmp/sparsefile2.img bs=1 count=0  oseek=1862g

And the array created with:

zpool create -f storage raidz2 gpt/disk01 gpt/disk02 gpt/disk03  \
gpt/disk04 gpt/disk05 /tmp/sparsefile1.img /tmp/sparsefile2.img

The -f flag was required to avoid this message:

invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: raidz contains both files and devices


I tried to offline one of the sparse files:

 zpool offline storage /tmp/sparsefile2.img

That caused a panic: http://www.langille.org/tmp/zpool-offline-panic.jpg

After rebooting, I rm'd both /tmp/sparsefile1.img  and 
/tmp/sparsefile2.img without thinking they were still in the zpool.  Now 
I am unable to destroy the pool.  The system panics.  I disabled ZFS via 
/etc/rc.conf, rebooted, recreated the two sparse files, then did a 
forcestart of zfs.  Then I saw:


# zpool status
  pool: storage
 state: ONLINE
status: One or more devices could not be used because the label is 
missing or

invalid.  Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-4J
 scrub: none requested
config:

NAME  STATE READ WRITE CKSUM
storage   ONLINE   0 0 0
  raidz2  ONLINE   0 0 0
gpt/disk01ONLINE   0 0 0
gpt/disk02ONLINE   0 0 0
gpt/disk03ONLINE   0 0 0
gpt/disk04ONLINE   0 0 0
gpt/disk05ONLINE   0 0 0
/tmp/sparsefile1.img  UNAVAIL  0 0 0  corrupted 
data
/tmp/sparsefile2.img  UNAVAIL  0 0 0  corrupted 
data


errors: No known data errors


Another attempt to destroy the array created a panic.

Suggestions as to how to remove this array and get started again?

--
Dan Langille - http://langille.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Dan Langille 

On 7/25/2010 1:58 PM, Dan Langille wrote:

I'm trying to destroy a zfs array which I recently created.  It contains
nothing of value.


Oh... I left this out:

FreeBSD kraken.unixathome.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Mar 
 5 00:46:11 EST 2010 
d...@kraken.example.org:/usr/obj/usr/src/sys/KRAKEN  amd64





# zpool status
pool: storage
state: ONLINE
status: One or more devices could not be used because the label is
missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
gpt/disk05 ONLINE 0 0 0
/tmp/sparsefile1.img UNAVAIL 0 0 0 corrupted data
/tmp/sparsefile2.img UNAVAIL 0 0 0 corrupted data

errors: No known data errors

Why sparse files? See this post:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1007077+0+archive/2010/freebsd-stable/20100725.freebsd-stable


The two tmp files were created via:

dd if=/dev/zero of=/tmp/sparsefile1.img bs=1 count=0 oseek=1862g
dd if=/dev/zero of=/tmp/sparsefile2.img bs=1 count=0 oseek=1862g

And the array created with:

zpool create -f storage raidz2 gpt/disk01 gpt/disk02 gpt/disk03 \
gpt/disk04 gpt/disk05 /tmp/sparsefile1.img /tmp/sparsefile2.img

The -f flag was required to avoid this message:

invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: raidz contains both files and devices


I tried to offline one of the sparse files:

zpool offline storage /tmp/sparsefile2.img

That caused a panic: http://www.langille.org/tmp/zpool-offline-panic.jpg

After rebooting, I rm'd both /tmp/sparsefile1.img and
/tmp/sparsefile2.img without thinking they were still in the zpool. Now
I am unable to destroy the pool. The system panics. I disabled ZFS via
/etc/rc.conf, rebooted, recreated the two sparse files, then did a
forcestart of zfs. Then I saw:

# zpool status
pool: storage
state: ONLINE
status: One or more devices could not be used because the label is
missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
gpt/disk05 ONLINE 0 0 0
/tmp/sparsefile1.img UNAVAIL 0 0 0 corrupted data
/tmp/sparsefile2.img UNAVAIL 0 0 0 corrupted data

errors: No known data errors


Another attempt to destroy the array created a panic.

Suggestions as to how to remove this array and get started again?




--
Dan Langille - http://langille.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Jeremy Chadwick 
On Sun, Jul 25, 2010 at 01:58:34PM -0400, Dan Langille wrote:
> [...]
> NAME  STATE READ WRITE CKSUM
> storage   ONLINE   0 0 0
>   raidz2  ONLINE   0 0 0
> gpt/disk01ONLINE   0 0 0
> gpt/disk02ONLINE   0 0 0
> gpt/disk03ONLINE   0 0 0
> gpt/disk04ONLINE   0 0 0
> gpt/disk05ONLINE   0 0 0
> /tmp/sparsefile1.img  UNAVAIL  0 0 0 corrupted data
> /tmp/sparsefile2.img  UNAVAIL  0 0 0 corrupted data
> 
> [...]
>
> Another attempt to destroy the array created a panic.
> Suggestions as to how to remove this array and get started again?
>
> [...]
>
> FreeBSD kraken.unixathome.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Mar  5 
> 00:46:11 EST 2010 d...@kraken.example.org:/usr/obj/usr/src/sys/KRAKEN  amd64

1) Try upgrading the system (to 8.1-STABLE).  There have been numerous
changes to ZFS on RELENG_8 since March 5th.  I don't know if any of them
would address your problem.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.4
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.3
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.2
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.1

2) Try bringing the system down into single-user mode and zeroing out
the first and last 64kbytes of each gpt/diskXX (you'll have to figure
this out on your own, I'm not familiar with GPT) so that the ZFS
metadata goes away.

Footnote: can someone explain to me how ZFS would, upon reboot, know
that /tmp/sparsefile[12].img are part of the pool?  How would ZFS taste
metadata in this situation?

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Volodymyr Kostyrko 

25.07.2010 23:18, Jeremy Chadwick wrote:

Footnote: can someone explain to me how ZFS would, upon reboot, know
that /tmp/sparsefile[12].img are part of the pool?  How would ZFS taste
metadata in this situation?


Just hacking it.

Each ZFS device which is part of the pool tracks all other devices which 
are part of the pool with their sizes, device ids, last known points. It 
doesn't know that /tmp/sparsefile[12].img is part of the pool, yet it 
does know that pool have had some /tmp/sparsefile[12].img before and now 
they can't be found or current contents doesn't look like ZFS device.


Can you try moving current files to /tmp/sparsefile[34].img and then 
readd them to the pool with zpool replace? One by one please.


--
Sphinx of black quartz judge my vow.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Dan Langille 

On 7/25/2010 4:37 PM, Volodymyr Kostyrko wrote:

25.07.2010 23:18, Jeremy Chadwick wrote:

Footnote: can someone explain to me how ZFS would, upon reboot, know
that /tmp/sparsefile[12].img are part of the pool? How would ZFS taste
metadata in this situation?


Just hacking it.

Each ZFS device which is part of the pool tracks all other devices which
are part of the pool with their sizes, device ids, last known points. It
doesn't know that /tmp/sparsefile[12].img is part of the pool, yet it
does know that pool have had some /tmp/sparsefile[12].img before and now
they can't be found or current contents doesn't look like ZFS device.

Can you try moving current files to /tmp/sparsefile[34].img and then
readd them to the pool with zpool replace? One by one please.


I do not know what the above paragraph means.

--
Dan Langille - http://langille.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

PCI access point card

2010-07-25 Thread Beach Geek 

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Volodymyr Kostyrko 

25.07.2010 20:58, Dan Langille wrote:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
gpt/disk05 ONLINE 0 0 0
/tmp/sparsefile1.img UNAVAIL 0 0 0 corrupted data
/tmp/sparsefile2.img UNAVAIL 0 0 0 corrupted data


0k, i'll try it from here. UNAVAIL means ZFS can't locate correct vdev 
for this pool member. Even if this file exists it's not used by ZFS 
because it lacks ZFS headers/footers.


You can (I think so) reinsert empty file to the pool with:

# zpool replace storage /tmp/sparsefile1.img /tmp/sparsefile1.img

^- pool ^- ZFS old vdev name ^- current file

If you replace both files you can theoretically bring pool to fully 
consistent state.


Also you can use md to convert files to devices:

# mdconfig -a -t vnode -f /tmp/sparsefile1.img
md0

And you can use md0 with your pool.

--
Sphinx of black quartz judge my vow.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Dan Langille 

On 7/25/2010 4:49 PM, Volodymyr Kostyrko wrote:

25.07.2010 20:58, Dan Langille wrote:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
gpt/disk05 ONLINE 0 0 0
/tmp/sparsefile1.img UNAVAIL 0 0 0 corrupted data
/tmp/sparsefile2.img UNAVAIL 0 0 0 corrupted data


0k, i'll try it from here. UNAVAIL means ZFS can't locate correct vdev
for this pool member. Even if this file exists it's not used by ZFS
because it lacks ZFS headers/footers.

You can (I think so) reinsert empty file to the pool with:

# zpool replace storage /tmp/sparsefile1.img /tmp/sparsefile1.img

^- pool ^- ZFS old vdev name ^- current file

If you replace both files you can theoretically bring pool to fully
consistent state.

Also you can use md to convert files to devices:

# mdconfig -a -t vnode -f /tmp/sparsefile1.img
md0

And you can use md0 with your pool.


FYI, tried this, got a panic:

errors: No known data errors
# mdconfig -a -t vnode -f /tmp/sparsefile1.img
md0
# mdconfig -a -t vnode -f /tmp/sparsefile2.img
md1
# zpool replace storage /tmp/sparsefile1.img /dev/md0


--
Dan Langille - http://langille.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

PCI AP card recommendations

2010-07-25 Thread Beach Geek 
Looking for feedback from people using FreeBSD v8.x as access points.
We will be using Pentium 3 boxes with 8-STABLE as APs.
Each box will have a unique SSID and use WPA2-PSK.
Each AP will be linked back to 2 gateways.

I'm looking for AP card suggestions and any helpful hints as far as the
APs.   Looking for card models, not chipsets.

Looking forward to hearing your experiences.
Thanks,
RJ

PS.  We're looking for info beyond the FreeBSD documentation, and related to
the 8.x branch.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zpool destroy causes panic

2010-07-25 Thread Dan Langille 

On 7/25/2010 1:58 PM, Dan Langille wrote:

I'm trying to destroy a zfs array which I recently created.  It contains
nothing of value.

# zpool status
pool: storage
state: ONLINE
status: One or more devices could not be used because the label is
missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
gpt/disk05 ONLINE 0 0 0
/tmp/sparsefile1.img UNAVAIL 0 0 0 corrupted data
/tmp/sparsefile2.img UNAVAIL 0 0 0 corrupted data

errors: No known data errors

Why sparse files? See this post:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1007077+0+archive/2010/freebsd-stable/20100725.freebsd-stable


The two tmp files were created via:

dd if=/dev/zero of=/tmp/sparsefile1.img bs=1 count=0 oseek=1862g
dd if=/dev/zero of=/tmp/sparsefile2.img bs=1 count=0 oseek=1862g

And the array created with:

zpool create -f storage raidz2 gpt/disk01 gpt/disk02 gpt/disk03 \
gpt/disk04 gpt/disk05 /tmp/sparsefile1.img /tmp/sparsefile2.img

The -f flag was required to avoid this message:

invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: raidz contains both files and devices


I tried to offline one of the sparse files:

zpool offline storage /tmp/sparsefile2.img

That caused a panic: http://www.langille.org/tmp/zpool-offline-panic.jpg

After rebooting, I rm'd both /tmp/sparsefile1.img and
/tmp/sparsefile2.img without thinking they were still in the zpool. Now
I am unable to destroy the pool. The system panics. I disabled ZFS via
/etc/rc.conf, rebooted, recreated the two sparse files, then did a
forcestart of zfs. Then I saw:

# zpool status
pool: storage
state: ONLINE
status: One or more devices could not be used because the label is
missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
gpt/disk05 ONLINE 0 0 0
/tmp/sparsefile1.img UNAVAIL 0 0 0 corrupted data
/tmp/sparsefile2.img UNAVAIL 0 0 0 corrupted data

errors: No known data errors


Another attempt to destroy the array created a panic.

Suggestions as to how to remove this array and get started again?


I fixed this by:

* reboot zfs_enable="NO" in /etc/rc.conf
* rm /boot/zfs/zpool.cache
* wiping the first and last 16KB of each partition involved in the array

Now I'm trying mdconfig instead of sparse files.  Making progress, but 
not all the way there yet.  :)


--
Dan Langille - http://langille.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[releng_8_1 tinderbox] failure on amd64/amd64

2010-07-25 Thread FreeBSD Tinderbox 
TB --- 2010-07-25 22:03:44 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-07-25 22:03:44 - starting RELENG_8_1 tinderbox run for amd64/amd64
TB --- 2010-07-25 22:03:44 - cleaning the object tree
TB --- 2010-07-25 22:04:07 - cvsupping the source tree
TB --- 2010-07-25 22:04:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8_1/amd64/amd64/supfile
TB --- 2010-07-25 22:04:55 - building world
TB --- 2010-07-25 22:04:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-07-25 22:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-07-25 22:04:55 - TARGET=amd64
TB --- 2010-07-25 22:04:55 - TARGET_ARCH=amd64
TB --- 2010-07-25 22:04:55 - TZ=UTC
TB --- 2010-07-25 22:04:55 - __MAKE_CONF=/dev/null
TB --- 2010-07-25 22:04:55 - cd /src
TB --- 2010-07-25 22:04:55 - /usr/bin/make -B buildworld
>>> World build started on Sun Jul 25 22:04:56 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -fpic -DPIC -O2 -pipe  -DZFS_NO_ACL 
-I/src/cddl/lib/libzfs/../../../sbin/mount 
-I/src/cddl/lib/libzfs/../../../cddl/lib/libumem 
-I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris 
-I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include 
-I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common 
-DNEE!
 D_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c 
/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c
 -o libzfs_changelist.So
cc -fpic -DPIC -O2 -pipe  -DZFS_NO_ACL 
-I/src/cddl/lib/libzfs/../../../sbin/mount 
-I/src/cddl/lib/libzfs/../../../cddl/lib/libumem 
-I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris 
-I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include 
-I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common 
-DNEE!
 D_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c 
/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_config.c
 -o libzfs_config.So
cc -fpic -DPIC -O2 -pipe  -DZFS_NO_ACL 
-I/src/cddl/lib/libzfs/../../../sbin/mount 
-I/src/cddl/lib/libzfs/../../../cddl/lib/libumem 
-I/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris 
-I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include 
-I/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head 
-I/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common 
-I/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common 
-DNEE!
 D_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -c 
/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c
 -o libzfs_import.So
/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c:
 In function 'zpool_in_use':
/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c:1219:
 inte

Re: gpart -b 34 versus gpart -b 1024

2010-07-25 Thread perryh 
Dmitry Morozovsky  wrote:
> ... sector numbers (in CHS address method)
> [start] at 1 (which always suprized me ;)

This goes back at least as far as soft-sectored 8" diskettes
in the CP/M era.

IIRC, physical sector 0 of each track contained the C number,
possibly the H, and a list of the remaining sectors on the track
including the size of each sector -- even within a single track
the sectors did not all have to be the same size.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Confirm your prize

2010-07-25 Thread alexs 
* Sandra Blaze  [2010-07-25 11:51:08 -0400]:

> Confirm your award prize!
> 
> Online Email Sweepstakes program Cisco Network Inc.,
> This is to inform you that your Email Address attached to a Ticket 
> Number(712-118-2010) has won the prize Sum of 500,000.00 Euro (Five hundred 
> thousand Euro Only),in an Email Sweepstakes program held on the 24th July 
> 2010.

Must i divide it on all maillist users? :(

> 
> Contact person: Dr. Richmond Williams
> TEL: +31-683-312-468
> reply to E-mail to: ciscoglobal...@netscape.net
> 
> Below are your Winning Datas:
> Email Ticket Number 612118-312006
> Reference Number: HP914711/31
> Batch Number : 00/7119/ILPP/HLPN
> Serial Number: 124554-21
> 
> Please note that all winning must be claim not later than 20th August 2010.
> 
> Sincerely,
> Sandra Blaze
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 
alexs
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"