Date: Tue, 26 Nov 2024 20:58:14 +0100 From: =?utf-8?Q?S=C3=B8ren_Schmidt?= <soren.schmidt@gmail.com> To: FreeBSD Current <freebsd-current@freebsd.org> Cc: Johan Hendriks <joh.hendriks@gmail.com> Subject: Re: IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information Message-ID: <6FCA01E4-FEFB-447B-9034-4D3BC0D0C335@gmail.com> In-Reply-To: <9f572320-bc01-41c2-9820-74844b6ec9f1@gmail.com> References: <CAPyFy2CMZ6BUC7PxOhgiEncGBOgFDHSNY4H0O-DCeW-q4giGVA@mail.gmail.com> <9f572320-bc01-41c2-9820-74844b6ec9f1@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 26 Nov 2024, at 13.31, Johan Hendriks <joh.hendriks@gmail.com> = wrote: >>=20 >> To test, set the loader tunable hw.mfi.mrsas_enable=3D1 in >> /boot/loader.conf. Confirm that mrsas is being used, and that the >> system functions properly. >>=20 > I use Dell servers and i set the loader tuneable = hw.mfi.mrsasa_enable=3D1 on these machines. I use ZFS, so no raid = functionality off the card itself. This works fine for me. I have not = have any issues. I use this setting as mrsas give me way nicer device = names, i do remember having boot issues with the mfi default. But that = is a long time ago. I have several Dell servers (R640/R740) running 14-stable using mrsas = and RAID10 volumes, UFS on FreeBSD, and I have experienced corrupted = filesystems on reboot on 3 out of 14 servers so its not consistent, its = the same servers that always fail though :)=20 However for our purposes we have set cache policy to write-through = instead of write-back (default) and that seems to have solved the issue. There is no real performance penalty at least with our workload. Would be nice to have this fixed though, seems like the cache is not = written to disk on reboot but if you force it through it works. Its just like when the backup battery on the controller dies, then a = reboot also messes up the disk :) -S=C3=B8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FCA01E4-FEFB-447B-9034-4D3BC0D0C335>