Announcement

Collapse
No announcement yet.

Systemd/Microsoft Effort For A Global Counter On Block/Disk Changes Coming To Linux 5.15

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • teknoraver
    replied
    If you want to have a look at (least one) bug solved by this counter, here is it:

    https://github.com/systemd/systemd/issues/17469

    Leave a comment:


  • reba
    replied
    Originally posted by teknoraver View Post
    Yes, it's also a counter of how many disks have been seen.
    What would be a use case for this?

    Originally posted by teknoraver View Post
    The filehandle was not feasable, because only root can open a handle to most disks, and creating fds is more expensive anyway.
    What we did, is just an incremental number to every disk registration, exposed to /sys
    Wouldn't have /dev/disk/by-uuid/... achieved the same and even more like:
    - detecting if a disk has been removed from the system if the uuid has gone missing
    - re-attaching the same disk on a different port (sdc -> sde) and still be able to use it transparently without a redetection and migration logic
    - no explicit support for another field and additional logic for that counter to do stuff
    - already etablished, nothing to add; to the kernel no less

    Leave a comment:


  • teknoraver
    replied
    Originally posted by Developer12 View Post

    So it's more of a counter of "how many different disks have been sda since boot?"

    It a counter strictly necessary for that? Wouldn't it be easier for both userspace and kernelspace to have a filehandle that expires on disk removal, as is the case for process filehandles when dealing with PID reuse?
    Yes, it's also a counter of how many disks have been seen.

    The filehandle was not feasable, because only root can open a handle to most disks, and creating fds is more expensive anyway.
    What we did, is just an incremental number to every disk registration, exposed to /sys

    Leave a comment:


  • Developer12
    replied
    Originally posted by teknoraver View Post
    Imagine to have an usb disk named /dev/sdd. You unplug and replug it, how can an application know that /dev/sdd is the same as 10 minutes ago?
    The number now increases for every disk registration, and it's unique since boot:
    So it's more of a counter of "how many different disks have been sda since boot?"

    It a counter strictly necessary for that? Wouldn't it be easier for both userspace and kernelspace to have a filehandle that expires on disk removal, as is the case for process filehandles when dealing with PID reuse?

    Leave a comment:


  • Developer12
    replied
    Originally posted by teknoraver View Post
    when finding an issue? Waiting for others to solve?
    I was wondering if this was going to become a cross-OS on-disk standard for (re-)identifying disks.

    Leave a comment:


  • teknoraver
    replied
    Originally posted by Developer12 View Post

    Is this number stored on-disk?

    If I understand you right, numbers map to disks and the one-to-one number<->disk mapping never changes, correct? (not incrementing with each operation done to the disk, like a sequence number)
    Imagine to have an usb disk named /dev/sdd. You unplug and replug it, how can an application know that /dev/sdd is the same as 10 minutes ago?
    The number now increases for every disk registration, and it's unique since boot:


    [email protected]:~# cat /sys/block/sdd/diskseq
    7
    [email protected]:~# cat /sys/block/sdd/diskseq
    10

    Originally posted by Developer12 View Post
    Why does microsoft have to be involved?
    What we should do when finding an issue? Waiting for others to solve?

    Leave a comment:


  • Ananace
    replied
    Originally posted by Developer12 View Post

    Is this number stored on-disk? Why does microsoft have to be involved?

    If I understand you right, numbers map to disks and the one-to-one number<->disk mapping never changes, correct? (not incrementing with each operation done to the disk, like a sequence number)
    The number is just something that the kernel tracks, so it's only stored as a memory value during runtime.
    Guessing that Microsoft has had issues with correctly handling hot mounting of storage while under load in either WSL or Azure, and they want something to improve it kernel side.

    The number would probably change if you were to unplug the drive and then plug it back in again, as - at that point - it'd be a new disk attached to the same system.

    As I understand it, this is just to make sure that when your application is set to use disk X, then it will only ever actually access disk X, never accidentally disk Y if something happens to swap them around - due to something like a USB hub resetting.

    Leave a comment:


  • Developer12
    replied
    Originally posted by Ananace View Post

    It's a number that refers to a particular disk, and only ever to that particular disk.

    Plug a disk in, it becomes 0 - and all applications that track disks can know that they're talking to disk 0, the next is 1, then 2, etc. None of the sd[whatever letter happened to be available at the time] stuff that can cause a new disk to suddenly occupy a name that referred to another disk earlier.
    Is this number stored on-disk? Why does microsoft have to be involved?

    If I understand you right, numbers map to disks and the one-to-one number<->disk mapping never changes, correct? (not incrementing with each operation done to the disk, like a sequence number)

    Leave a comment:


  • Ananace
    replied
    Originally posted by Developer12 View Post
    Can someone actually clarify wtf this is? Is it an on-disk number? Or a counter that starts at zero when a device is mounted and incremented when it's touched? If the latter, why does microsoft need to be involved? Not a very clear explanation in the article.
    It's a number that refers to a particular disk, and only ever to that particular disk.

    Plug a disk in, it becomes 0 - and all applications that track disks can know that they're talking to disk 0, the next is 1, then 2, etc. None of the sd[whatever letter happened to be available at the time] stuff that can cause a new disk to suddenly occupy a name that referred to another disk earlier.

    Leave a comment:


  • Developer12
    replied
    Can someone actually clarify wtf this is? Is it an on-disk number? Or a counter that starts at zero when a device is mounted and incremented when it's touched? If the latter, why does microsoft need to be involved? Not a very clear explanation in the article.

    Leave a comment:

Working...
X