Code Monkey home page Code Monkey logo

Comments (6)

lundman avatar lundman commented on August 30, 2024

A quick test program

#include <stdio.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/mman.h>

int main(int argc, char **argv)
{
    unsigned char buffer[256];
    int i, fd;
    unsigned char *addy = NULL;
    unsigned int off = 0;

    for (i = 0; i < 256; i++)
        buffer[i] = i;

    fd = open("/BOOM/file", O_TRUNC|O_CREAT|O_RDWR, 0644);
    if (fd < 0) exit(1);

    for (i = 0; i < 240808; i+=256)
        write(fd, buffer, 256);

    close(fd);

    fd = open("/BOOM/file", O_RDONLY);
    if (fd<0) exit(2);

    addy = mmap(NULL,240808, PROT_READ, MAP_FILE|MAP_PRIVATE, fd, 0);
    if (addy==MAP_FAILED) {
        perror("mmap");
        exit(3);
    }

    printf("reading with mmap (%p)\n", addy);

    off = 0x2ac30;
    printf("Bytes at offset 0x%04x are:\n", off);

    for (i = 0; i < 16; i++)
        printf("0x%02x ", addy[off+i]);
    printf("\n");

    munmap(addy, fd);
    close(fd);
    return 0;
}

# hexdump -C /BOOM/file|less
0002ac30  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|

# ./map_test 
reading with mmap (0x103ca7000)
Bytes at offset 0x2ac30 are:
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 
Jul  2 14:28:36 Lundmans-Mac kernel[0]: +vnop_pagein: off 0 size 32768
Jul  2 14:28:36 Lundmans-Mac kernel[0]: vaddr 0xffffff805bafd000 with upl_off 0
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 0 into address 0xffffff805bafd000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 1000 into address 0xffffff805bafe000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 2000 into address 0xffffff805baff000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 3000 into address 0xffffff805bb00000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 4000 into address 0xffffff805bb01000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 5000 into address 0xffffff805bb02000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 6000 into address 0xffffff805bb03000
Jul  2 14:28:36 Lundmans-Mac kernel[0]: reading from off 7000 into address 0xffffff805bb04000

So clearly it is not quite right.

from zfs.

lundman avatar lundman commented on August 30, 2024

Hmm actually, no, now that I test it some more, it is doing the right thing. I need to go deeper.

from zfs.

lundman avatar lundman commented on August 30, 2024

I wonder if our "HOLES" are not zero-filled, perhaps that is the real issue:

Seed set to 1372752561
truncating to largest ever: 0x1497c
data miscompare @ 16880
LOG DUMP (5 total operations):
1: SKIPPED (no operation)
2: SKIPPED (no operation)
3: SKIPPED (no operation)
4: TRUNCATE UP     from 0x0 (0) to 0x1497c (84348)      ******WWWW
5: READ            0x41f0 (16880) thru 0xfc53 (64595)   (0xba64 (47716) bytes) ***RRRR***
data miscompare @ 16880
OFFSET     GOOD       BAD        LENGTH     BADOP#   Last: WRITE    TRUNC-   TRUNC+  
0x0000d000 0x00000000 0x00000006 0x00000830 -1             -1       -1       4  

from zfs.

lundman avatar lundman commented on August 30, 2024

Ok, I spent the last few hours over the mmap/mappedread/pagein and pageout functions. At no point did I manage to show that they failed to work correctly.

.. until I took out the test to "truncate down". This stopped the fsx tester from failing.

It would seem that we have pages for a file, say at offset $offset. We then truncate the file anywhere before $offset, which should invalidate those pages that follow after.

Then, if we extend forward again, we should be getting zero-pages, but mappedread does in fact get the old pages.

It would seem we need logic in zfs_truncate() which invalidates all pages beyond the truncate point.

from zfs.

lundman avatar lundman commented on August 30, 2024

Actually all that should be handled by

    ubc_setsize(vp, end);

It will invalidate all pages after end as well as zero out the last half block. And yet, this is not enough to fix all the problems. But it does make it better.

from zfs.

lundman avatar lundman commented on August 30, 2024

Hah! Ok, fixing the SPL to call ubc_setsize() took care of it, we had more places where the size had to be correctly set. Also brought in dmu_write_pages which completes mmap work. fsx no longer need special flags to run, it completes all the runs for the last hour.

openzfsonosx/spl@0a2e5ce
edd93cc

from zfs.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.