Date: Wed, 19 Nov 2014 03:11:39 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: d@delphij.net Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@FreeBSD.org> Subject: Re: svn commit: r274673 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <20141118231139.GO9763@zxy.spb.ru> In-Reply-To: <546BCEF1.7080009@delphij.net> References: <201411181840.sAIIe2C7094558@svn.freebsd.org> <20141118220030.GA31347@zxy.spb.ru> <546BCEF1.7080009@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 18, 2014 at 02:57:53PM -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/18/14 14:00, Slawa Olhovchenkov wrote: > > On Tue, Nov 18, 2014 at 06:40:02PM +0000, Xin LI wrote: > > > >> Author: delphij Date: Tue Nov 18 18:40:01 2014 New Revision: > >> 274673 URL: https://svnweb.freebsd.org/changeset/base/274673 > >> > >> Log: Allow tuning zfs_max_recordsize via loader tunable. Tuning > >> is NOT recommended. > > > > This is not tuning, this is simple guard. And can be safe changed > > (incrased, at the least) in any time. > > FWIW: It can be safely decreased: the ability to read such pool is > maintained. > > > For some workload optimal is maximum, i.e. 16MB. > > > > May be better comment: increasing this value required strong > > understaning after-effects of increasing memory consumption and > > bulk data transfers. (sorry for english) > > That's true, but not free. I don't think we have carefully evaluated > the situation (and possible mitigation measures, like, do we need to > make some improvements to the slab allocator? It's never exposed to > workload like this before, etc.), and people tend to make uninformed > changes all the times (a lot of FreeBSD tuning guide gives wrong > instructions). Now I start production with raidz1 and recordsize 2MB. > >> Requested by: Slawa Olhovchenkov <slw zxy spb ru> MFC after: 2 > >> weeks > > > > Thanks, can you allow RW? > > Sure, done in 274681. > > I didn't do it at the beginning because I don't think it's a good idea > to make it easy for users to fiddle with it, and power users who > actually need to tweak do not change it often. But you are right > there is no real technical reason not to allow read-write. Thanks, just bad if required reboot creating zfs set with >1MB recordsize. At this point site may be in prodation, for example. > >> Modified: > >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c > >> > >> > >> > Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c > >> ============================================================================== > >> > >> > - --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c > Tue Nov 18 18:03:40 2014 (r274672) > >> +++ > >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c > >> Tue Nov 18 18:40:01 2014 (r274673) @@ -51,6 +51,8 @@ #include > >> <sys/dsl_userhold.h> #include <sys/dsl_bookmark.h> > >> > >> +SYSCTL_DECL(_vfs_zfs); + /* * The SPA supports block sizes up to > >> 16MB. However, very large blocks * can have an impact on i/o > >> latency (e.g. tying up a spinning disk for @@ -61,6 +63,9 @@ * of > >> this setting. */ int zfs_max_recordsize = 1 * 1024 * 1024; > >> +SYSCTL_INT(_vfs_zfs, OID_AUTO, max_recordsize, CTLFLAG_RDTUN, + > >> &zfs_max_recordsize, 0, + "Maximum block size. Expect dragons > >> when tuning this."); > >> > >> #define SWITCH64(x, y) \ { \ > >> _______________________________________________ > >> svn-src-all@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/svn-src-all To > >> unsubscribe, send any mail to > >> "svn-src-all-unsubscribe@freebsd.org" > > > - -- > Xin LI <delphij@delphij.net> https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0 > > iQIcBAEBCgAGBQJUa87xAAoJEJW2GBstM+nsPrgP/0o9O/AiiFJZhCezZc29oMQe > Za4m5U3sWCPTb1x5fc3A5pKq1frT2GUvbUAjh21yuN5A8GfMt8A4v+nQ4i/asZ3C > GkyU7Zkv0sW/14DR3nhRrLTNCum6p2Yk0XkxDBnUlBVzoJzbbbqin9PtTbe6i330 > mav6E17V0AelCk8BoWpnhCcQbLObP9zvklzqknjlPHl5d81ERhfyp1p+BjPexdML > ykOb3ZsjC0+8MfNmlKEyUga6Saz6vQXVqtXhkMuvqE8VNSfedXO+EpOweOID2SDU > 7S4bwkFfu0GuBdqHSXTWsp3ncNiN/KfuX5fAUjb8Aoqp2RCHbft+DS2mnxSw/S7/ > cUpOoC1ga+cUU4KLEgm3DG8y1LZH3KPyrzwFzXfY31lgOttCosQi9IeWgigGW975 > 3jhU7Oz+CX6oMPoAWhujAD3yGKVp2Qp2lePl12pl+F73jrwJ7UaTbKWZlNkofX0T > o9/u/tqtna7NY3w9/z7WRDQFZvFEp2laARNAlr8QcakIuCXsDnG26LxFHbtLld0M > R/88EYYJgWLPWD7TzapkrKhqbaf6sn6Z7m4M0Oo+MbFRNSII59/rTZsAbDI9PgiZ > ScnaQldbnJdi0yMp8VyHrPDFqJtByhL/dQvmcTYf2QItnFEu1Hf3Os1nD+p3+8Z+ > sdEBf8XuZdlMIcRIzFR2 > =Gccl > -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141118231139.GO9763>