Re: kern/178388: [zfs] [patch] allow up to 8MB recordsize
The following reply was made to PR kern/178388; it has been noted by GNATS. From: Matthew Rezny To: Adam Nowacki Cc: bug-follo...@freebsd.org Subject: Re: kern/178388: [zfs] [patch] allow up to 8MB recordsize Date: Wed, 8 May 2013 13:09:44 +0200 On Tue, 07 May 2013 18:46:05 +0200 Adam Nowacki wrote: > On 2013-05-07 16:11, Matthew Rezny wrote: > > The proposed patch is rather ugly. Is there some reason to not > > simply change the definition of SPA_MAXBLOCKSIZE? > > Yes. Altering the value of SPA_MAXBLOCKSIZE will change the sizes of > certain metadata objects that will break compatibility with > non-patched systems. Just importing the pool on system with modified > SPA_MAXBLOCKSIZE would result in this pool being inaccessible in > non-patched systems - forever. It will also prevent booting from zfs > pools as there is not enough memory available in the bootloader to > support large block sizes for metadata or the loader files. > That is understandable and something I had thought about but not verified if it were the case. > > The point of defining a constant is it can then be changed in the > > place it's defined rather than in every place it's used. Having to > > go change every reference to it is error prone as missing a single > > reference could wreck havoc. > > SPA_MAXBLOCKSIZE is used for far more than just a limit - in many > places it is used as a default block size. I'm introducing > SPA_BIGBLOCKSIZE because of the above compatibility problems and > using it only in places that are essential to supporting large block > sizes for file or zvol data leaving default block sizes unmodified > (especially for pool metadata). The changed block size is only in > effect when recordsize dataset property is modified by explicit > action of the administrator. Existing and new datasets created post > patch default to backwards compatible 128k block size. > > SPA_BIGBLOCKSIZE is used for asserts on the size of read/written > block, ARC cache, recordsize property bounds checks and block size > calculation logic. > > The names of the constants could probably be changed: > current SPA_MAXBLOCKSIZE to SPA_DEFAULTBLOCKSIZE > and the new SPA_BIGBLOCKSIZE to SPA_MAXBLOCKSIZE. > Changing the value of SPA_MAXBLOCKSIZE while defining SPA_DEFAULTBLOCKSIZE (or SPA_MAXCOMPATBLOCKSIZE as I almost suggested) with the prior value would be clearer in terms of both naming and patch readability. I will venture so say that the number of references to the SPA_DEFAULTBLOCKSIZE will be fewer than references to SPA_MAXBLOCKSIZE. > > Specifically, I call into question the effect this has on the > > definition of SPA_BLOCKSIZES. The reference to SPA_MAXBLOCKSIZE was > > not replaced by SPA_BIGBLOCKSIZE and thus SPA_BLOCKSIZES is > > insufficiently sized to represent all the possible block sizes that > > could be used. > > The SPA_BLOCKSIZES define is never used in the code and should > probably be removed. > In that case, please kill it now. > > That one jumped out at me when I skimmed over the patch. I have not > > reviewed all the ZFS code to look for other unchanged references > > that are not part of the patch context. > > Keep in mind that I have been using this for two months now on 3 > systems, 5 zpools and a total of over 50TB data written post-patch > with varying record sizes (128k, 1MB, 4MB, 8MB). All systems boot > directly from the big pools using unmodified (128k limited) > bootloader. Thank you for your work in this area and the extensive testing you have done. Do you have any performance data from these tests that you can share? Do you have some reason for not going beyond 8MB record size (diminishing returns, etc)? I have put some thought to additional compression algorithms in ZFS, e.g. LZMA, which would require large record size to see significant gains over existing gzip support. High strength compression on large data chunks would be slow for data frequently written, but for an archival filesystem where data is written once and then read periodically it would be quite useful. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
conf/178421: [PATCH] compile_et needs to be built with bootstrap-tools for buildworld when WITH_KERBEROS is set
>Number: 178421 >Category: conf >Synopsis: [PATCH] compile_et needs to be built with bootstrap-tools for >buildworld when WITH_KERBEROS is set >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 08 15:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release:10-CURRENT >Organization: EMC Isilon >Environment: FreeBSD fuji-current.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+6a3d3f6-dirty: Sat Apr 27 16:03:39 PDT 2013 root@fuji-current.local:/usr/obj/usr/src/sys/FUJI i386 >Description: I've seen the following error when running make tinderbox with SRCCONF=/dev/null __MAKE_CONF=/dev/null on a system without kerberos on it: compile_et /usr/src.svn/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et make: exec(compile_et) failed (No such file or directory) The issue can be resolved like so: Index: Makefile.inc1 === --- Makefile.inc1 (revision 250324) +++ Makefile.inc1 (working copy) @@ -1176,7 +1180,8 @@ kerberos5/lib/libroken \ kerberos5/lib/libvers \ kerberos5/tools/asn1_compile \ - kerberos5/tools/slc + kerberos5/tools/slc \ + usr.bin/compile_et .endif >How-To-Repeat: make buildworld installworld -DWITHOUT_KERBEROS SRCCONF=/dev/null __MAKE_CONF=/dev/null make buildworld -DWITH_KERBEROS SRCCONF=/dev/null __MAKE_CONF=/dev/null >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/178422: [PATCH] don't be picky about case with yes/no prompt in growfs(8)
>Number: 178422
>Category: bin
>Synopsis: [PATCH] don't be picky about case with yes/no prompt in
>growfs(8)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed May 08 16:00:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:10-CURRENT
>Organization:
EMC Isilon
>Environment:
FreeBSD fuji-current.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0
r+6a3d3f6-dirty: Sat Apr 27 16:03:39 PDT 2013
root@fuji-current.local:/usr/obj/usr/src/sys/FUJI i386
>Description:
The attached patch changes the prompt check from strcmp to strcasecmp so I dont
have to type in "Yes" exactly in order to use growfs interactively.
>How-To-Repeat:
md=$(mdconfig -a -t malloc -s 100m)
newfs -s 50m /dev/$md
sh -c 'newfs -s $(( 50 * 1024 * 1024 / 512 )) /dev/$md'
growfs /dev/$md
>Fix:
Patch attached with submission follows:
>From f30baf745ad8704685fd32701c7bd492129c05da Mon Sep 17 00:00:00 2001
From: Garrett Cooper
Date: Wed, 8 May 2013 08:41:08 -0700
Subject: [PATCH] Don't be picky with case for yes/no prompt
Signed-off-by: Garrett Cooper
---
sbin/growfs/growfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sbin/growfs/growfs.c b/sbin/growfs/growfs.c
index fe49efb..e011a1b 100644
--- a/sbin/growfs/growfs.c
+++ b/sbin/growfs/growfs.c
@@ -1544,7 +1544,7 @@ main(int argc, char **argv)
printf(" from %s to %s? [Yes/No] ", oldsizebuf, newsizebuf);
fflush(stdout);
fgets(reply, (int)sizeof(reply), stdin);
- if (strcmp(reply, "Yes\n")){
+ if (strcasecmp(reply, "yes\n") != 0) {
printf("\nNothing done\n");
exit (0);
}
--
1.8.2
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/178422: [PATCH] don't be picky about case with yes/no prompt in growfs(8)
Synopsis: [PATCH] don't be picky about case with yes/no prompt in growfs(8) Responsible-Changed-From-To: freebsd-bugs->eadler Responsible-Changed-By: eadler Responsible-Changed-When: Wed May 8 17:15:03 UTC 2013 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=178422 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178387: [zfs] [patch] sparse files performance improvements
Synopsis: [zfs] [patch] sparse files performance improvements Responsible-Changed-From-To: freebsd-bugs->zfs-devel Responsible-Changed-By: delphij Responsible-Changed-When: Wed May 8 20:01:52 UTC 2013 Responsible-Changed-Why: Over to zfs-devel@ for review. http://www.freebsd.org/cgi/query-pr.cgi?pr=178387 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/168485: hwpmc(4) sampling stops working on P4
Synopsis: hwpmc(4) sampling stops working on P4 Responsible-Changed-From-To: freebsd-bugs->hiren Responsible-Changed-By: hiren Responsible-Changed-When: Wed May 8 20:03:04 UTC 2013 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=168485 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178412: [smbfs] Coredump when smbfs mounted
Old Synopsis: Coredump when smbfs mounted New Synopsis: [smbfs] Coredump when smbfs mounted Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 8 21:31:55 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178412 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178388: [zfs] [patch] allow up to 8MB recordsize
Synopsis: [zfs] [patch] allow up to 8MB recordsize Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 8 21:34:09 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178388 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178411: [ral] [panic] FreeBSD kernel crash in rt2860
Old Synopsis: FreeBSD kernel crash in rt2860 New Synopsis: [ral] [panic] FreeBSD kernel crash in rt2860 Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 8 21:37:33 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178411 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
SRe: bin/166181: [patch] calendar(1): calendar -a does not work
The following reply was made to PR bin/166181; it has been noted by GNATS. From: mla_str...@att.net To: bug-follo...@freebsd.org, grandi@noao Cc: mla_str...@att.net Subject: SRe: bin/166181: [patch] calendar(1): calendar -a does not work Date: Wed, 8 May 2013 16:21:30 -0700 (PDT) > > Proposed patch causes information from ALL calendars on the system to be > mailed to each user. Not an acceptable solution. > I confess to not understanding how the calendar program code is supposed to work. I may have confused it by using the same user id for two different password file entries. I noticed, for example, that lines from one user's calendar file were sometimes mailed to the other user. I have since given up on running "calendar -a" via the /etc/periodic mechanism and now just run calendar for myself out of my own crontab. So far this seems to work. Dan Strick mla_str...@att.net ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/178436: [PATCH] devel/gsoap doesn't work with make reinstall
>Number: 178436
>Category: misc
>Synopsis: [PATCH] devel/gsoap doesn't work with make reinstall
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu May 09 00:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:n/a
>Organization:
EMC Isilon
>Environment:
n/a
>Description:
devel/gsoap uses ${LN} instead of ${LN} -f which results in build failures when
make reinstall is invoked on the port:
devel/gsoap: ln: /usr/local/lib/gsoap/stdsoap2.cpp: File exists
devel/gsoap: *** [post-install] Error code 1
devel/gsoap:
devel/gsoap: Stop in /usr/ports/devel/gsoap.
devel/gsoap: *** [/usr/ports/devel/gsoap/work/.install_done.gsoap._usr_local]
Error code 1
devel/gsoap:
devel/gsoap: Stop in /usr/ports/devel/gsoap.
devel/gsoap: *** [reinstall] Error code 1
devel/gsoap:
devel/gsoap: Stop in /usr/ports/devel/gsoap.
** Wed May 8 23:11:36 2013: devel/gsoap failed in 3 seconds (status 256) **
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
>From 07799c10ab909b5c2bd368c0891f952d6739a98d Mon Sep 17 00:00:00 2001
From: Garrett Cooper
Date: Wed, 8 May 2013 16:14:02 -0700
Subject: [PATCH 1/2] Fix make reinstall with devel/gsoap
Signed-off-by: Garrett Cooper
---
devel/gsoap/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devel/gsoap/Makefile b/devel/gsoap/Makefile
index b9bb340..f7787f3 100644
--- a/devel/gsoap/Makefile
+++ b/devel/gsoap/Makefile
@@ -53,6 +53,6 @@ post-patch:
post-install:
@${MKDIR} ${PREFIX}/lib/gsoap
@${CP} ${WRKSRC}/gsoap/stdsoap2.c ${PREFIX}/lib/gsoap
- @${LN} ${PREFIX}/lib/gsoap/stdsoap2.c ${PREFIX}/lib/gsoap/stdsoap2.cpp
+ @${LN} -f ${PREFIX}/lib/gsoap/stdsoap2.c
${PREFIX}/lib/gsoap/stdsoap2.cpp
.include
--
1.8.2
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/178436: [PATCH] devel/gsoap doesn't work with make reinstall
Synopsis: [PATCH] devel/gsoap doesn't work with make reinstall Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 9 00:44:27 UTC 2013 Responsible-Changed-Why: ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=178436 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.
The following reply was made to PR bin/174711; it has been noted by GNATS.
From: Eitan Adler
To: bug-followup
Cc:
Subject: Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.
Date: Wed, 8 May 2013 21:54:47 -0400
-- Forwarded message --
From: Emil Mamedov
Date: 7 May 2013 11:30
Subject: Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.
To: freebsd-bugs@freebsd.org
The following reply was made to PR bin/174711; it has been noted by GNATS.
From: Emil Mamedov
To: freebsd-gnats-sub...@freebsd.org, freebsd-i...@freebsd.org
Cc:
Subject: Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.
Date: Tue, 7 May 2013 08:26:57 -0700 (PDT)
My previous tarball has been corrupted and I've attached
floppy-diff files to message body:
--- fdc.c.org 2012-03-03 06:15:13.0 +
+++ fdc.c 2013-01-21 23:18:14.0 +
@@ -136,33 +136,35 @@
*/
static struct fd_type fd_searchlist_360k[] = {
- { FDF_5_360 },
+ { FDD_5_360 | FL_AUTO},
+ { FDD_5_180 | FL_AUTO},
{ 0 }
};
static struct fd_type fd_searchlist_12m[] = {
- { FDF_5_1200 | FL_AUTO },
- { FDF_5_360 | FL_2STEP | FL_AUTO},
+ { FHD_5_1200 | FL_AUTO },
+ { FHD_5_360 | FL_2STEP | FL_AUTO},
+ { FHD_5_180 | FL_2STEP | FL_AUTO},
{ 0 }
};
static struct fd_type fd_searchlist_720k[] = {
- { FDF_3_720 },
+ { FHD_3_720 },
{ 0 }
};
static struct fd_type fd_searchlist_144m[] = {
- { FDF_3_1440 | FL_AUTO},
- { FDF_3_720 | FL_AUTO},
+ { FHD_3_1440 | FL_AUTO},
+ { FHD_3_720 | FL_AUTO},
{ 0 }
};
static struct fd_type fd_searchlist_288m[] = {
- { FDF_3_1440 | FL_AUTO },
+ { FHD_3_1440 | FL_AUTO },
#if 0
- { FDF_3_2880 | FL_AUTO }, /* XXX: probably doesn't work */
+ { FHD_3_2880 | FL_AUTO }, /* XXX: probably doesn't work */
#endif
- { FDF_3_720 | FL_AUTO},
+ { FHD_3_720 | FL_AUTO},
{ 0 }
};
@@ -297,7 +299,7 @@
fdprinttype(struct fd_type *ft)
{
- printf("(%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,0x%x)",
+ printf("(%d,%d,0x%x,0x%x,%d,%d,%d,%d,0x%x,%d,%d,0x%x)\n",
ft->sectrac, ft->secsize, ft->datalen, ft->gap, ft->tracks,
ft->size, ft->trans, ft->heads, ft->f_gap, ft->f_inter,
ft->offset_side2, ft->flags);
@@ -856,7 +858,8 @@
return (fdc_biodone(fdc, ENXIO));
/* Check if we lost our media */
- if (fdin_rd(fdc) & FDI_DCHG) {
+ if ((fdin_rd(fdc) & FDI_DCHG) &&
+ !(device_get_flags(fd->dev) & FD_NO_CHLINE)) {
if (debugflags & 0x40)
printf("Lost disk\n");
mtx_lock(&fdc->fdc_mtx);
@@ -884,7 +887,7 @@
mfm = (fd->ft->flags & FL_MFM)? NE7CMD_MFM: 0;
steptrac = (fd->ft->flags & FL_2STEP)? 2: 1;
- i = fd->ft->sectrac * fd->ft->heads;
+ i = fd->ft->sectrac * fd->ft->heads; //sectors per cyl
cylinder = bp->bio_pblkno / i;
descyl = cylinder * steptrac;
sec = bp->bio_pblkno % i;
@@ -928,6 +931,22 @@
* Enhanced controllers do implied seeks for read&write as long as
* we do not need multiple steps per track.
*/
+ /* But if DD diskette in HD FDD then disable do implied seek */
+ if (fdc->fdct == FDC_ENHANCED) {
+ int imp_seek;
+ if (fd->ft->flags & FL_2STEP) imp_seek = 0x00;
+ else imp_seek = 0x40;
+ if (fdc_cmd(fdc, 4,
+ I8207X_CONFIG,
+ 0,
+ imp_seek | /* Disable/Enable Implied Seek */
+ 0x10 | /* Polling disabled */
+ (fifo_threshold - 1), /* Fifo threshold */
+ 0x00, /* Precomp track */
+ 0))
+ device_printf(fdc->fdc_dev,
+ " CONFIGURE failed\n");
+ }
if (cylinder != fd->track && (
fdc->fdct != FDC_ENHANCED ||
descyl != cylinder ||
@@ -1229,7 +1248,9 @@
if (fdc_sense_int(fdc, &st0, &cyl) == FD_NOT_VALID)
goto done; /* XXX */
*recal |= (1 << fd->fdsu);
- if (fdin_rd(fdc) & FDI_DCHG) {
+
+ if ((fdin_rd(fdc) & FDI_DCHG) &&
+ !(device_get_flags(fd->dev) & FD_NO_CHLINE)) {
if (debugflags & 0x40)
printf("Empty in probe\n");
mtx_lock(&fdc->fdc_mtx);
@@ -1238,8 +1259,8 @@
} else {
if (fdc_sense_drive(fdc, &st3) != 0)
goto done;
- if (debugflags & 0x40)
- printf("Got disk in probe\n");
+//if (debugflags & 0x40)
+//printf("Got disk in probe\n");
