| 1 |
On 31/7/21 11:14 am, William Kenworthy wrote: |
| 2 |
> On 30/7/21 10:29 pm, Rich Freeman wrote: |
| 3 |
>> On Fri, Jul 30, 2021 at 1:14 AM William Kenworthy <billk@×××××××××.au> wrote: |
| 4 |
>>> 2. btrfs scrub (a couple of days) |
| 5 |
>>> |
| 6 |
>> Was this a read-only scrub, or did this involve repair (such as after |
| 7 |
>> losing a disk/etc)? |
| 8 |
>> |
| 9 |
>> My understanding of SMR is that it is supposed to perform identically |
| 10 |
>> to CMR for reads. If you've just recently done a bunch of writes I |
| 11 |
>> could see there being some slowdown due to garbage collection (the |
| 12 |
>> drive has a CMR cache which gets written out to the SMR regions), but |
| 13 |
>> other than that I'd think that reads would perform normally. |
| 14 |
>> |
| 15 |
>> Now, writes are a whole different matter and SMR is going to perform |
| 16 |
>> terribly unless it is a host-managed drive (which the consumer drives |
| 17 |
>> aren't), and the filesystem is SMR-aware. I'm not aware of anything |
| 18 |
>> FOSS but in theory a log-based filesystem should do just fine on |
| 19 |
>> host-managed SMR, or at least as well as it would do on CMR (log-based |
| 20 |
>> filesystems tend to get fragmented, which is a problem on non-SSDs |
| 21 |
>> unless the application isn't prone to fragmentation in the first |
| 22 |
>> place, such as for logs). |
| 23 |
>> |
| 24 |
>> Honestly I feel like the whole SMR thing is a missed opportunity, |
| 25 |
>> mainly because manufacturers decided to use it as a way to save a few |
| 26 |
>> bucks instead of as a new technology that can be embraced as long as |
| 27 |
>> you understand its benefits and limitations. One thing I don't get is |
| 28 |
>> why it is showing up on all sorts of smaller drives. I'd think the |
| 29 |
>> main application would be for large drives - maybe a drive that is |
| 30 |
>> 14TB as CMR could have been formatted as 20TB as SMR for the same |
| 31 |
>> price, and somebody could make that trade-off if it was worth it for |
| 32 |
>> the application. Using it on smaller drives where are more likely to |
| 33 |
>> be general-purpose is just going to cause issues for consumers who |
| 34 |
>> have no idea what they're getting into, particularly since the changes |
| 35 |
>> were sneaked into the product line. Somebody really needs to lose |
| 36 |
>> their job over this... |
| 37 |
>> |
| 38 |
> No, it was a normal scrub (read only is an option) - I did the scrub |
| 39 |
> hoping it wasn't necessary but aware that crash halting the OS while |
| 40 |
> doing a backup while the system was generating ooops after an upgrade |
| 41 |
> wasn't going to guarantee a clean shutdown. Ive just kicked off a scrub |
| 42 |
> -r and am getting 41Mb/s speed via the status check (its a usb3 on the |
| 43 |
> disk side, and usb2 on the PC - configuration: driver=usb-storage |
| 44 |
> maxpower=30mA speed=480Mbit/s). I will monitor for a couple of hours and |
| 45 |
> see what happens then swap to a standard scrub and compare the read rate. |
| 46 |
> |
| 47 |
> rattus ~ # date && btrfs scrub status |
| 48 |
> /run/media/wdk/cae17311-19ca-4e3c-b476-304e02c50694 |
| 49 |
> Sat 31 Jul 2021 10:55:43 AWST |
| 50 |
> UUID: cae17311-19ca-4e3c-b476-304e02c50694 |
| 51 |
> Scrub started: Sat Jul 31 10:52:07 2021 |
| 52 |
> Status: running |
| 53 |
> Duration: 0:03:35 |
| 54 |
> Time left: 22:30:40 |
| 55 |
> ETA: Sun Aug 1 09:26:23 2021 |
| 56 |
> Total to scrub: 3.23TiB |
| 57 |
> Bytes scrubbed: 8.75GiB (0.26%) |
| 58 |
> Rate: 41.69MiB/s |
| 59 |
> |
| 60 |
> Error summary: no errors found |
| 61 |
> |
| 62 |
> |
| 63 |
> lsusb: Bus 003 Device 007: ID 0bc2:331a Seagate RSS LLC Desktop HDD 5TB |
| 64 |
> (ST5000DM000) |
| 65 |
> |
| 66 |
> (seagate lists it as a 5Tb drive managed SMR) |
| 67 |
> |
| 68 |
> It was sold as a USB3 4Tb desktop expansion drive, fdisk -l shows "Disk |
| 69 |
> /dev/sde: 3.64 TiB, 4000787029504 bytes, 7814037167 sectors" and Seagate |
| 70 |
> is calling it 5Tb - marketing! |
| 71 |
> |
| 72 |
> BillK |
| 73 |
> |
| 74 |
> |
| 75 |
> |
| 76 |
> |
| 77 |
Still almost same scrub speed and 22.5 hours after running for nearly 2 |
| 78 |
1/2 hours. |
| 79 |
|
| 80 |
rattus ~ # btrfs scrub status |
| 81 |
/run/media/wdk/cae17311-19ca-4e3c-b476-304e02c50694 |
| 82 |
|
| 83 |
UUID: cae17311-19ca-4e3c-b476-304e02c50694 |
| 84 |
Scrub started: Sat Jul 31 10:52:07 2021 |
| 85 |
Status: running |
| 86 |
Duration: 2:22:44 |
| 87 |
Time left: 20:04:49 |
| 88 |
ETA: Sun Aug 1 09:19:43 2021 |
| 89 |
Total to scrub: 3.23TiB |
| 90 |
Bytes scrubbed: 350.41GiB (10.59%) |
| 91 |
Rate: 41.90MiB/s |
| 92 |
Error summary: no errors found |
| 93 |
rattus ~ # |
| 94 |
|
| 95 |
|
| 96 |
Cancelled and restarted it as a normal scrub - same speed/timings - I |
| 97 |
think if errors are found, thats when it would slow down. |
| 98 |
|
| 99 |
rattus ~ # btrfs scrub status |
| 100 |
/run/media/wdk/cae17311-19ca-4e3c-b476-304e02c50694 |
| 101 |
UUID: cae17311-19ca-4e3c-b476-304e02c50694 |
| 102 |
Scrub started: Sat Jul 31 13:18:51 2021 |
| 103 |
Status: running |
| 104 |
Duration: 0:00:05 |
| 105 |
Time left: 22:27:47 |
| 106 |
ETA: Sun Aug 1 11:46:43 2021 |
| 107 |
Total to scrub: 3.23TiB |
| 108 |
Bytes scrubbed: 209.45MiB (0.01%) |
| 109 |
Rate: 41.89MiB/s |
| 110 |
Error summary: no errors found |
| 111 |
rattus ~ # |
| 112 |
|
| 113 |
BillK |
Archives