Subject: Re: disklabeling a 5 TB partition!?
To: Brian Buhrow <buhrow@lothlorien.nfbcal.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 08/08/2006 09:29:29
--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 07, 2006 at 09:24:45PM -0700, Brian Buhrow wrote:
> On Aug 7,  8:59pm, Bill Studenmund wrote:
> } Subject: Re: disklabeling a 5 TB partition!?
> }=20
> } Huh? How does the partition type being used impact the RAID system's=3D=
20
> } ability (or inability) to calculate parity?
> }=20
> } Yes, parity on a multi-TB volume is a big (and irritating) deal. But I=
=3D20
> }	 don't see how partitioning or the lack there of will impact it.
> 	Perhaps things have changed since last I tried, but as I remember,
> when I had a filesystem on /dev/raid0d of a raid5 set some years ago under
> NetBSD-1.5 and 1.6/i386, I couldn't run raidctl -P on that mounted
> filesystem because the system complained that the device was busy.  Also,
> if I started the raid check before the filesystem was mounted, mount would
> complain that the device was busy until after the parity calculation was
> completed.

Ahhh... That's a consequence of using the same device node for mounting=20
and for RAID control. So that makes sense.

I'm not sure why the parity regen would cause an issue, unless the parity=
=20
regeneration keeps the device open during regeneration.

> 	I concluded that in order to do background parity checks, I had to put
> filesystems on raid sets on partitions other than the raw partition.  If
> this is wrong, then please correct me and let me know what I did in error.

If you aren't running at high securelevel, you should be able, I think, to=
=20
use the raw device (/dev/rraid...) for control. If you can't, we should=20
look into this.

Take care,

Bill

--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFE2LvpWz+3JHUci9cRAjaQAJ9FKlI0eiI4oho1Jw0IsKreo5fHzACfSHIQ
auNITwf8haD8fiFH17L4/0Y=
=ZcbM
-----END PGP SIGNATURE-----

--cWoXeonUoKmBZSoM--