| 1 |
On Fri, May 22, 2020 at 12:15 PM Dale <rdalek1967@×××××.com> wrote: |
| 2 |
> |
| 3 |
> The thing about the one I have now in use by LVM for /home, one is SMR and one is PMR. Even if the OS is aware, does it even know which drive the data is going to end up being stored on? I'm pretty sure since the PMR drive was in use before the SMR that the PMR is likely full. From my understanding, LVM doesn't balance the data out. It will fill up a drive and then move on to the next. If you add another, it will fill up the 2nd drive and then start on the newly added drive. Maybe it does do some magic but does the OS know which drive data is going to hit? |
| 4 |
> |
| 5 |
|
| 6 |
So, as far as I'm aware nothing on linux is natively optimized for |
| 7 |
SMR. I'm sure some people use host-managed SMR drives on linux for |
| 8 |
application-specific writing, but they're probably writing raw blocks |
| 9 |
without using a filesystem. |
| 10 |
|
| 11 |
However, if anything was going to be made SMR-aware then it would have |
| 12 |
to be implemented at all block layers, just like barrier support. I |
| 13 |
think back in the early days of barrier support some layers didn't |
| 14 |
support it, and a barrier can only make it from the filesystem to the |
| 15 |
drive if it is implemented in lmv+mdadm+driver and so on. |
| 16 |
|
| 17 |
If somebody added SMR support to ext4 but not to LVM then ext4 |
| 18 |
wouldn't detect the LV as an SMR drive, because lvm wouldn't pass that |
| 19 |
through. |
| 20 |
|
| 21 |
I suspect sooner or later a solution will emerge, but it could be a |
| 22 |
while. I suspect any solution would be for drives that could be set |
| 23 |
to be host-managed, because otherwise you're working around an extra |
| 24 |
layer of obfuscation. Maybe you could have trim support without |
| 25 |
further optimization, but that obviously isn't ideal. |
| 26 |
|
| 27 |
-- |
| 28 |
Rich |
Archives