0

After writing a sector to disk with DIRECT IO:

#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <time.h>

#define SECTOR_SIZE 512

int main(int argc, char *argv[]) {
    int offset = 0x2000000;
    int length = 4;
    int rc = -1;

    char *sector = (char*) aligned_alloc(SECTOR_SIZE, length*SECTOR_SIZE);
    memset(sector, 0, length*SECTOR_SIZE);

    int fd=open("/dev/sdd", O_RDWR | O_DIRECT);

    for (int i = 0; i < length*SECTOR_SIZE; i++) {
        sector[(i)] = (i&0xFF);
    }
    lseek(fd, offset, SEEK_SET);
    rc = write(fd, sector, length*SECTOR_SIZE);


    free(sector);
    close(fd);
}

The OS (Linux Mint 18.3, HP Elite 8000) revalidates each time the sector is written. The disk messages:

Apr 28 11:11:08 rp-mint-primary kernel: [427606.669411] scsi 4:0:0:0: Direct-Access     ATA      ST3160215ACE     A    PQ: 0 ANSI: 5
Apr 28 11:11:08 rp-mint-primary kernel: [427606.716607] sd 4:0:0:0: [sdd] 312581808 512-byte logical blocks: (160 GB/149 GiB)
Apr 28 11:11:08 rp-mint-primary kernel: [427606.716632] sd 4:0:0:0: [sdd] Write Protect is off
Apr 28 11:11:08 rp-mint-primary kernel: [427606.716636] sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Apr 28 11:11:08 rp-mint-primary kernel: [427606.716655] sd 4:0:0:0: Attached scsi generic sg4 type 0
Apr 28 11:11:08 rp-mint-primary kernel: [427606.716673] sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Apr 28 11:11:08 rp-mint-primary kernel: [427606.750419]  sdd: sdd1 sdd2
Apr 28 11:11:08 rp-mint-primary kernel: [427606.751102] sd 4:0:0:0: [sdd] Attached SCSI disk
Apr 28 11:16:30 rp-mint-primary kernel: [427929.080622]  sdd: sdd1 sdd2
Apr 28 11:16:36 rp-mint-primary kernel: [427934.631877]  sdd: sdd1 sdd2

The last line is output after each sector write completes without error, but the disk is inaccessible for about a second, which causes a major slowdown in the loop that stores data in the sector. Mint 17 would stop doing this after a few accesses, but 18 never stops. Is there an {ATTR} or some switch that can be set to stop the revalidate, if that is what is actually happening? Searching libata has yielded no help, and being a hardware developer, I am easily lost in the weeds here.

BTW don't run the program, it is using the disk as a "superfloppy", and will corrupt any data that was in the sector it writes to.

A little further information I have found: The "sdd: sdd1 sdd2" only happens after a write to the sector when a valid partition table exists on the hard drive. If the partition table is zeroed out, the OS reads MANY sectors of data from the disk (about .3 seconds worth), and the process exits silently, with no indication (that I can find) of what exactly happened. I have tried to turn on verbose messages from all the modules I can find that option for.

Is there maybe a kernel debug switch to examine IOCTL transactions to a specific device?

1 Answer 1

0

The revalidate behavior was found to be from the file manager 'Automount' option. Any time a write to the disk with O_DIRECT set will cause the os to remount all of the partitions on that disk. Setting the file manager behavior tab to disable automount solved it for my application.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .