Re: [List] Re: [List] Re: ZFS - reboot during resilver doesn't work

From: Frank Leonhardt <freebsd-doc_at_fjl.co.uk>
Date: Wed, 10 Sep 2025 10:52:57 UTC
On 10/09/2025 04:00, David Christensen wrote:
> On 9/8/25 16:33, David Christensen wrote:
>> I assume there are good use-cases for SMR drives, but I am not using
>> them.
>
>
> On 9/9/25 03:39, Frank Leonhardt wrote:
>> For the curious, these are 2TB Seagate Barracudas (which used to be
>> good drives), one first generation and one latest generation. They
>> were only 900Gb full, although I don't think that would affect the
>> re-silver speed (only the time). They're used for backing up
>> datasets, not intended for performance. I certainly wouldn't want
>> SMR on a database (or as backing store for a Windoze VM).
>
>
> The SMR disk should be a good fit for:
>
> 1.  Windows System Image Backup.  It appears that each partition is 
> mostly stored in a single large *.vhdx file.
>
> 2.  Windows Backup and Restore (Windows 7).  It appears that each 
> backup set is mostly composed of many 100~200 MB *.zip files.
>
They also seem fine for ZFS if you're storing backups on them. As I 
mentioned earlier in the thread, it managed a sustained sequential write 
(of 2Tb) at ~250MB/s, which is substantially more than the generation 1 
CMR version could manage.

I'll leave backing up Windows to someone else though.

Interesting development - I tried a scrub through a reboot and I'm 
seeing similar nonsense stats from zpool status on that too:

   scan: scrub in progress since Tue Sep  9 21:20:23 2025
         215G / 953G scanned at 131B/s, 100G / 953G issued at 61B/s
         0B repaired, 10.53% done, no estimated completion time

61 bytes per second? I could be waiting a long time! Except iostat is 
showing 115MB/second. Before the reboot the scrub was showing this as 
the issue speed. Either it's a bug or it means something completely 
different to what I assume it means, where "read" refers to the rate of 
requests issued for data to examine and "issued" is the figure for 
output data entering the queue (or possibly leaving it). Unless anyone 
can convince me it means something different, I may be posting this as a 
bug as it's quite easy to reproduce - kick of a scrub, note the rates, 
reboot and see silly figures.

Regards, Frank.




Regards, Frank.

Regards, Frank.