[9fans] devsd & media changed errors - Plan9

This is a discussion on [9fans] devsd & media changed errors - Plan9 ; when a disk or a cdrom reports that it has 0 sectors devsd won't let you write to the control file. it gives write error: media or partition has changed. this is because sdinitpart increments the partition vers each time ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [9fans] devsd & media changed errors

  1. [9fans] devsd & media changed errors

    when a disk or a cdrom reports that it has 0 sectors
    devsd won't let you write to the control file. it gives

    write error: media or partition has changed.

    this is because sdinitpart increments the partition vers
    each time it is called and it's called in many places when
    the number of sectors is zero.

    there are a couple of senerios where this is a pain.
    first, if you have a blank cdrom in the tray, you can't

    echo dma on>/dev/sdXX/ctl

    worse, if i have a drive that sometimes needs to be reset
    manually. (some sata drives have loopy firmware.) i can't

    echo reset>/dev/sdE5/ctl

    to fix it. (one could abuse /dev/sdctl to do this, but then
    you've reinvented the problem of figuring out which
    device is the intended target of the request.)

    am i missing something here or is this a real devsd
    problem? without knowing a whole lot about devsd,
    i would think that the devsd should allow writes to
    the control file even when sectors == 0. perhaps
    letting -1 sectors be the sentinal value would be enough.

    - erik

  2. Re: [9fans] devsd & media changed errors

    > when a disk or a cdrom reports that it has 0 sectors
    > devsd won't let you write to the control file. it gives


    this is not true. what is true is that if you open
    the ctl file and then the media changes, then you
    are required to reopen the ctl file in order to start
    using it. this is true of all the disk files.

    > first, if you have a blank cdrom in the tray, you can't
    >
    > echo dma on>/dev/sdXX/ctl


    i can't test this, but i don't believe this is true.
    (see above.)

    > worse, if i have a drive that sometimes needs to be reset
    > manually. (some sata drives have loopy firmware.) i can't
    >
    > echo reset>/dev/sdE5/ctl
    >
    > to fix it.


    i *know* this isn't true. i do this all the time (personally i think
    the sdmv driver is not quite driving the disks right).

    since ctl is used for things like partitioning the disk, i think
    it is reasonable that if the disk has changed since you
    opened the file, then you should need to reopen it.

    i do find it annoying that when i reset a disk this way,
    it appears to the sd framework as if the underlying
    disk has changed, so all the partitions go away, and
    all the open file descriptors get poisoned, but i'm not
    sure this is incorrect behavior. the media did sort of
    change -- it went away and came back.

    in venti i have worked around this by reloading the
    partition table and then reopening the file descriptors,
    but that's admittedly a pain.

    russ


  3. Re: [9fans] devsd & media changed errors

    >> when a disk or a cdrom reports that it has 0 sectors
    >> devsd won't let you write to the control file. it gives

    >
    >this is not true. what is true is that if you open
    >the ctl file and then the media changes, then you
    >are required to reopen the ctl file in order to start
    >using it. this is true of all the disk files.


    russ, you are not correct. i just retried using the pc/sdata
    driver.

    > first, if you have a blank cdrom in the tray, you can't
    >
    > echo dma on>/dev/sdXX/ctl
    >i can't test this, but i don't believe this is true.
    >(see above.)


    this is cut-n-paste from just now. i ejected a blank disk and reinserted it.

    ladd# cat ctl
    inquiry TSSTcorpCD/DVDW SH-S182MSB00 0726 0137PL
    config 85C0 capabilities 0F00 dma 00550004 dmactl 00000000
    ladd# echo dma on>ctl
    echo: write error: media or partition has changed
    ladd# echo dma on>ctl
    echo: write error: media or partition has changed

    scuzz is able to identify, though.

    >> worse, if i have a drive that sometimes needs to be reset
    >> manually. (some sata drives have loopy firmware.) i can't
    >>
    >> echo reset>/dev/sdE5/ctl
    >>
    >> to fix it.


    >i *know* this isn't true. i do this all the time (personally i think
    >the sdmv driver is not quite driving the disks right).


    i wasn't using the sdmv50xx driver. i have had similar results with
    the sdata driver and a new driver that i'm working on.

    > since ctl is used for things like partitioning the disk, i think
    > it is reasonable that if the disk has changed since you
    > opened the file, then you should need to reopen it.


    this sounds reasonable to me.

    > i do find it annoying that when i reset a disk this way,
    > it appears to the sd framework as if the underlying
    > disk has changed, so all the partitions go away, and
    > all the open file descriptors get poisoned, but i'm not
    > sure this is incorrect behavior. the media did sort of
    > change -- it went away and came back.


    i consider this a driver problem. in the ahci driver i'm currently
    working on, if "new" drive has the same serial# as the old drive,
    i don't report a media change.

    admittedly, this is a huristic becaus you could have removed the
    drive, paved it and put it back. but that might fall under the
    "deserves to loose" banner. in any event, the drive can't ever
    say with confidence that all the data is the same as was written.

    - erik

  4. Re: [9fans] devsd & media changed errors

    > this is cut-n-paste from just now. i ejected a blank disk and reinserted it.
    >
    > ladd# cat ctl
    > inquiry TSSTcorpCD/DVDW SH-S182MSB00 0726 0137PL
    > config 85C0 capabilities 0F00 dma 00550004 dmactl 00000000
    > ladd# echo dma on>ctl
    > echo: write error: media or partition has changed
    > ladd# echo dma on>ctl
    > echo: write error: media or partition has changed
    >
    > scuzz is able to identify, though.


    bizarre.

    this is cut-n-paste from just now, with a blank dvd in the drive:

    cpu% cat /dev/sdC1/ctl
    inquiry MAT****ADVD-RAM LF-D310 A12608/01/02
    config 85C0 capabilities 0F00 dma 00550004 dmactl 00550004
    cpu% echo dma on >/dev/sdC1/ctl
    cpu%

    sure enough, though, if i do it the way you did:

    cpu% cd /dev/sdC1
    cpu% cat ctl
    inquiry MAT****ADVD-RAM LF-D310 A12608/01/02
    config 85C0 capabilities 0F00 dma 00550004 dmactl 00550004
    cpu% echo dma on >ctl
    echo: write error: i/o error
    cpu%

    that's a different error, but close enough (if the attempt at
    rescanning the disk produced an error then you wouldn't
    get to the media change).

    i see what's going on: your example runs *in* the /dev/sdC1
    directory, and every time a lookup happens in that directory
    while the size is zero, the version does get bumped:

    cpu% ls -q /dev/sdC1
    (0000000004301005 263 00) /dev/sdC1/ctl
    (0000000004301006 264 00) /dev/sdC1/raw
    cpu% ls -q /dev/sdC1
    (0000000004301005 273 00) /dev/sdC1/ctl
    (0000000004301006 274 00) /dev/sdC1/raw
    cpu%

    so when you run "echo dma on >ctl", that causes an open of
    ctl and then an exec of echo. the exec of echo rescans /dev/sdC1
    and the version on everything gets bumped, so by the time
    echo does the write, the open ctl is treated as out-of-date.

    if i change the path to look in /bin for echo before ., then
    working in /dev/sdC1 is okay:

    cpu% path=(/bin .)
    cpu% cd /dev/sdC1
    cpu% cat ctl
    inquiry MAT****ADVD-RAM LF-D310 A12608/01/02
    config 85C0 capabilities 0F00 dma 00550004 dmactl 00550004
    cpu% echo dma on >ctl
    cpu%

    so it sounds like the problem is that sdinitpart should not
    bump the version number if the drive size is zero and the
    last time it was called the drive size was zero too.

    > i consider this a driver problem. in the ahci driver i'm currently
    > working on, if "new" drive has the same serial# as the old drive,
    > i don't report a media change.
    >
    > admittedly, this is a huristic because you could have removed the
    > drive, paved it and put it back. but that might fall under the
    > "deserves to loose" banner. in any event, the drive can't ever
    > say with confidence that all the data is the same as was written.


    i think that if you yank the disk and put it back in,
    that's a media change and the version should change.
    (the same thing happens if you eject a cd and put the
    same one back in.)

    it would be great if the ducks could be lined up so that
    the version number doesn't change on disk reset though,
    but as you say that is more of an underlying driver issue.
    (in fact, sdmv is the only driver in the distribution with
    a "reset" ctl message, so the version-change-on-reset
    problem is at the moment specific to sdmv.)

    russ


+ Reply to Thread