Date: Wed, 17 Jul 2013 11:35:19 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: =?ISO-8859-15?Q?Gezeala_M=2E_Bacu=F1o_II?= <gezeala@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Slow resilvering with mirrored ZIL Message-ID: <alpine.BSF.2.00.1307171111460.91446@wonkity.com> In-Reply-To: <CAJKO3mWqUTB22Hu=Ce%2By_0Om96Ai1ZgLL_3dEcC4p6DXoy3YLQ@mail.gmail.com> References: <CABBFC07-68C2-4F43-9AFC-920D8C34282E@unixconn.com> <2EF46A8C-6908-4160-BF99-EC610B3EA771@alumni.chalmers.se> <51D437E2.4060101@digsys.bg> <E5CCC8F551CA4627A3C7376AD63A83CC@multiplay.co.uk> <CBCA1716-A3EC-4E3B-AE0A-3C8028F6AACF@alumni.chalmers.se> <20130704000405.GA75529@icarus.home.lan> <C8C696C0-2963-4868-8BB8-6987B47C3460@alumni.chalmers.se> <20130704171637.GA94539@icarus.home.lan> <2A261BEA-4452-4F6A-8EFB-90A54D79CBB9@alumni.chalmers.se> <20130704191203.GA95642@icarus.home.lan> <43015E9015084CA6BAC6978F39D22E8B@multiplay.co.uk> <CAOjFWZ4obK1cSmvTpW%2Bt4xKdMf%2BkJV5w-sujDT1AZoepj%2B5YrA@mail.gmail.com> <3CFB4564D8EB4A6A9BCE2AFCC5B6E400@multiplay.co.uk> <51D6A206.2020303@digsys.bg> <CAOjFWZ5CWV3UZRppM3nTehfTPaw1N%2Bw6LjsEZZGxE16DOkS%2BGA@mail.gmail.com> <CAJKO3mW=ahm7sBdjGc-b2tN3D7%2BQH7gR7UPt24RsqUdZf=%2BjvA@mail.gmail.com> <alpine.BSF.2.00.1307161935020.84500@wonkity.com> <CAJKO3mWqUTB22Hu=Ce%2By_0Om96Ai1ZgLL_3dEcC4p6DXoy3YLQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3512871622-236036210-1374082519=:91446 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 17 Jul 2013, Gezeala M. Bacuņo II wrote: > If ZFS goes on a bare drive, it will be aligned by default. If ZFS is going in a partition, yes, align that partition to 4K boundaries or larger multiples of 4K, like 1M. > > Your statement is enlightening and concise, exactly what I need. Thanks. > > The gnop/ashift workaround is just to get ZFS to use the right block size. So if you don't take care to get partition alignment right, you might end up using the right > block size but misaligned. > > And yes, it will be nice to be able to just explicitly tell ZFS the block size to use. > > > We do add the entire drive (no partitions) to ZFS, perform gnop/ashift and other necessary steps and then verify ashift=12 through zdb. > > The gpart/gnop/ashift steps, if I understand correctly (do correct me if I'm stating this incorrectly), is needed for further SSD performance tuning. Taking into consideration leaving a > certain chunk for wear leveling and also if the SSD has a size that may be too big for L2ARC. Well, there are several things going on. Partitions can be used for a couple of things. Limiting the size of space available to ZFS, leaving an unallocated part of the drive for wear leveling. Note that ZFS on FreeBSD now has TRIM, which should make leaving unused space on SSDs unnecessary. Aligning partitions preserves performance. If a partition is misaligned, writes can slow down to half speed. For example, a 4K filesystem block written to an aligned partition writes a single block. If the partition is misaligned, that 4K write is split over two disk blocks. Each block has to be read, partly modified, then written, taking roughly twice as long. Finally, ZFS's ashift controls the minimum size of block ZFS uses. ashift=12 (12 bits) sets that to 4K blocks (2^12=4096). Again, a performance thing, matching the filesystem block size to device block size. It would be interesting to see a benchmark of ZFS on a 4K drive with different ashift values. --3512871622-236036210-1374082519=:91446--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1307171111460.91446>