svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Pawel Jakub Dawidek]

On Mon, Dec 06, 2010 at 09:28:42PM +0100, Ivan Voras wrote:
> But there are two reasons that I think are important, which resulted
> in changing this:
> 
> 1) It is being used out of the original context in the mailing list
> posts I've referenced - it was being used (and in a worse way, by
> having a hacked zpool binary) for alignment like I did in the patch,
> despite that the sectorsize wasn't changed.

FreeBSD is not Solaris, really. ZFS has a lot of code that is not needed
in FreeBSD. For example we don't need to partition raw disks and use
partition, we can simply use raw disks (or any other GEOM provider),
thanks to GEOM. I also think that Solaris needs a lot of work to support
4kB sectors. We don't. We are prepared for that for a long time now.
As I said many times now, doing such a change in ZFS will of course work
for you, but it doesn't solve the problem properly. It doesn't solve the
problem for all the other disks consumers. If you want to use hacked
zpool binary that's fine by me, but don't commit this.

> 2) The solaris "big sector" project, described in
> http://arc.opensolaris.org/caselog/PSARC/2008/769/final_spec.txt
> basically blesses ZFS to work with big sectors, and states "ZFS can
> automatically run on larger sector size disk after the label change
> and I/O path change." Since the effect of having a larger sectorsize
> will effectively be only the change in ashift, this is what I've done.

Hmm, what kind of argument is that? Yes, ZFS can work with larger
sectors just fine. I have many such installations where I use ZFS on top
of 4kB GELI providers. What this sentence describe is simply that ZFS is
4kB-sector ready. What you did actually suggest that ZFS can work only
with 512 byte sectors, so you need to change alignment internally, which
is not true - there is no need to modify ZFS, because it can support
disks with larger sectors.

> > BTW. ZFS is no longer open-source if you didn't notice.
> 
> I have noticed but I don't understand how it affects FreeBSD. I would
> like to discuss this sometime but unless you have some urgent
> interpretation of this information, I think it's best to start another
> thread about it.

I'm just saying that discussing anything upstream is much harder now.

PS. Do you know your change breaks all current ZFS installation if
stripesize is defined for a provider?

	# zpool create tank ada0
	(upgrade FreeBSD so that ada0 now reports 4kB stripesize)
	# zpool import tank
	cannot import 'tank': invalid vdev configuration

So you change was not only poorly thought out and not reviewed, but also
not even minimally tested. Before we go any further, back it out.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20101207/88dbd01c/attachment.pgp