Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Accessing past end of object #121

Closed
behlendorf opened this issue Feb 24, 2011 · 3 comments
Closed

Accessing past end of object #121

behlendorf opened this issue Feb 24, 2011 · 3 comments
Milestone
0.6.0

Comments

@behlendorf
Copy link
Contributor

Reported in zfs-discuss. The following crash occurred after roughly a day of use. The error indicates that we attempted to access beyond the end of an object. I've cleaned up and added the stack from the zfs-discuss list.

As a work around setting 'zfs_recover = 1' will prevent the panic and simply return an error to the application. I suspect it's an upstream ZFS v28 pool issue not related to the Linux port because what looks to be an identical issue has been reported in the FreeBSD port which is based on v28.

http://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009380.html

zfs: accessing past end of object 3c/3569 (size=4608 access=4104+585)
SPLError: 27870:0:(spl- err.c:48:vpanic()) SPL PANIC
SPL: Showing stack for process 27870
Pid: 27870, comm: encfs Tainted: P   M        2.6.35.10-74.fc14.x86_64 #1
Call Trace:
[] spl_debug_dumpstack+0x30/0x32 [spl]
[] spl_debug_bug+0x88/0xcd [spl]
[] vpanic+0x65/0x83 [spl] 
[] vcmn_err+0x38/0x75 [spl]
[] zfs_panic_recover+0x52/0x54 [zfs]
[] dmu_buf_hold_array_by_dnode+0xb4/0x32d [zfs]
[] dmu_write_uio_dnode+0x47/0x123 [zfs]
[] dmu_write_uio_dbuf+0x49/0x5f [zfs]
[] zfs_write+0x61d/0xa24 [zfs]
[] zpl_write_common+0x52/0x6a [zfs]
[] zpl_write+0x5f/0x82 [zfs]
[] ? security_file_permission+0x16/0x18
[] vfs_write+0xac/0x100
[] sys_pwrite64+0x5a/0x76 
[] system_call_fastpath+0x16/0x1b
@db48x
Copy link

db48x commented Feb 24, 2011

Thanks. This pool is version 23, created by zfs-fuse. What other information will you need?

 pool: tank
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
    still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
    pool will no longer be accessible on older software versions.
 scan: scrub in progress since Thu Feb 24 04:06:24 2011
    2.76T scanned out of 4.85T at 110M/s, 5h32m to go
    0 repaired, 56.94% done
config:

    NAME                                         STATE     READ WRITE CKSUM
    tank                                         ONLINE       0     0     0
      raidz1-0                                   ONLINE       0     0     0
        ata-WDC_WD20EARS-00S8B1_WD-WCAVY2304352  ONLINE       0     0     0
        ata-WDC_WD20EARS-00S8B1_WD-WCAVY2449350  ONLINE       0     0     0
        ata-WDC_WD20EARS-00S8B1_WD-WCAVY2454409  ONLINE       0     0     0
        wwn-0x50014ee2aeb3644d                   ONLINE       0     0     0
        ata-WDC_WD20EARS-00S8B1_WD-WCAVY2657307  ONLINE       0     0     0

errors: No known data errors

@behlendorf
Copy link
Contributor Author

Hopefully that will be enough info, I'll try and talk with the Solaris guys and see if this isn't already fixed upstream.

@behlendorf
Copy link
Contributor Author

Closing issue, I've heard no additional reports of this in the last 8 months. It has been a one time event as far as I can tell.

@inevity inevity mentioned this issue Oct 11, 2014
Closed
@bud4 bud4 mentioned this issue Dec 1, 2017
Closed
richardelling pushed a commit to richardelling/zfs that referenced this issue Oct 15, 2018
@vishnuitta
feat(snap_rebuild): ignore internally created snapshots while returni…
98e57e7 
…ng snap_zv (openzfs#121)

... for given io_num
Signed-off-by: Vishnu Itta <vitta@mayadata.io>
sdimitro pushed a commit to sdimitro/zfs that referenced this issue Feb 14, 2022
@tonynguien
DOSE-961 Invalidate zcache devices between tests and after ZTS run (o…
4e0782f 
…penzfs#121)
rkojedzinszky pushed a commit to rkojedzinszky/zfs that referenced this issue Mar 7, 2023
@anodos325
Fix ZFS_READONLY implementation on Linux (openzfs#121)
e83c40b 
MS-FSCC 2.6 is the governing document for
DOS attribute behavior. It specifies the following:

For a file, applications can read the file but
cannot write to it or delete it. For a directory,
applications cannot delete it, but applications can
create and delete files from the directory.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
ixhamza pushed a commit to ixhamza/zfs that referenced this issue Nov 15, 2023
@anodos325 @ixhamza
Fix ZFS_READONLY implementation on Linux (openzfs#121)
09a0c8a 
MS-FSCC 2.6 is the governing document for
DOS attribute behavior. It specifies the following:

For a file, applications can read the file but
cannot write to it or delete it. For a directory,
applications cannot delete it, but applications can
create and delete files from the directory.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
arter97 pushed a commit to arter97/zfs that referenced this issue Nov 23, 2023
@anodos325 @arter97
Fix ZFS_READONLY implementation on Linux (openzfs#121)
317053b 
MS-FSCC 2.6 is the governing document for
DOS attribute behavior. It specifies the following:

For a file, applications can read the file but
cannot write to it or delete it. For a directory,
applications cannot delete it, but applications can
create and delete files from the directory.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
ixhamza pushed a commit to ixhamza/zfs that referenced this issue Jun 13, 2024
@anodos325 @ixhamza
Fix ZFS_READONLY implementation on Linux (openzfs#121)
815f61f 
MS-FSCC 2.6 is the governing document for
DOS attribute behavior. It specifies the following:

For a file, applications can read the file but
cannot write to it or delete it. For a directory,
applications cannot delete it, but applications can
create and delete files from the directory.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.6.0
Development

No branches or pull requests
2 participants
@behlendorf @db48x