Project

General

Profile

Bug #4638

Panic in ZFS via rfs3_setattr()/rfs3_write(): dirtying snapshot!

Added by Marcel Telka over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
zfs - Zettabyte File System
Start date:
2014-02-27
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

> ::panicinfo ! grep message
         message dirtying snapshot!
> $C
ffffff009c872bd0 vpanic()
ffffff009c872c00 0xfffffffff79a36a5()
ffffff009c872c70 dnode_setdirty_sc+0xe9(ffffff15fb386ce8, ffffff15a45e68c0, 1)
ffffff009c872d10 dbuf_dirty_sc+0x2df(ffffff159f04b650, ffffff15a45e68c0, 1)
ffffff009c872db0 dbuf_dirty_sc+0x291(ffffff15ef60b198, ffffff15a45e68c0, 1)
ffffff009c872e50 dbuf_dirty_sc+0x291(ffffff15855e61b0, ffffff15a45e68c0, 1)
ffffff009c872ef0 dbuf_dirty_sc+0x291(ffffff15cd979d48, ffffff15a45e68c0, 1)
ffffff009c872f90 dbuf_dirty_sc+0x291(ffffff159f04bdd0, ffffff15a45e68c0, 1)
ffffff009c873030 dbuf_dirty_sc+0x291(ffffff159f04be90, ffffff15a45e68c0, 1)
ffffff009c8730d0 dbuf_dirty_sc+0x291(ffffff15e044e790, ffffff15a45e68c0, 1)
ffffff009c873140 dnode_setdirty_sc+0xdd(ffffff16084fc408, ffffff15a45e68c0, 1)
ffffff009c873160 dnode_setdirty+0x1a(ffffff16084fc408, ffffff15a45e68c0)
ffffff009c873220 dnode_free_range+0x361(ffffff16084fc408, 0, 200, ffffff15a45e68c0)
ffffff009c8732a0 dmu_free_long_range_impl+0xbe(ffffff15ac9a5a80, ffffff16084fc408, 0, ffffffffffffffff)
ffffff009c873310 dmu_free_long_range+0x62(ffffff15ac9a5a80, 10, 0, ffffffffffffffff)
ffffff009c8733c0 zfs_trunc+0x7b(ffffff1620211e90, 0)
ffffff009c873500 zfs_freesp+0xc5(ffffff1620211e90, 0, 0, 2, 1)
ffffff009c873590 zfs_space+0x134(ffffff161cf22c40, b, ffffff009c8737a0, 2, 0, ffffff156deef3a0, ffffff009c8737e0)
ffffff009c873620 fop_space+0x59(ffffff161cf22c40, b, ffffff009c8737a0, 2, 0, ffffff156deef3a0, ffffff009c8737e0)
ffffff009c873860 rfs3_setattr+0x62c(ffffff009c873a00, ffffff009c8738c0, ffffff15f4162b00, ffffff009c873c00, ffffff156deef3a0)
ffffff009c873b80 common_dispatch+0x475(ffffff009c873c00, ffffff159b398000, 2, 4, fffffffff845d376, ffffffffc0169060)
ffffff009c873ba0 rfs_dispatch+0x2d(ffffff009c873c00, ffffff159b398000)
ffffff009c873c80 svc_getreq+0x1c1(ffffff159b398000, ffffff158c4d0ac0)
ffffff009c873cf0 svc_run+0xe0(ffffff16306c3140)
ffffff009c873d30 svc_do_run+0x8e(1)
ffffff009c873e20 nfssys+0xf1(e, fed00fbc)
ffffff009c873ec0 dtrace_systrace_syscall32+0xe4(e, fed00fbc, 6a649700, 8944a8c0, 1, 0)
ffffff009c873f10 _sys_sysenter_post_swapgs+0x149()

Steps to Reproduce:

1. Create an NFS share with zfs property snapdir=visible
2. Mount the share from a Server 2008 R2 system (probably same on Windows 7) via Windows NFS client, as in example below:

c:\\>mount 10.6.1.51:/volumes/ssd/resource-ssd L:\\
L: is now successfully connected to 10.6.1.51:/volumes/ssd/resource-ssd

The command completed successfully.

3. Create a file from Windows.
4. Snapshot the share on the Nexenta side.
5. Go to L:\\.zfs\\snapshot\\<name>\\
6. Echo something to the file you've created from Windows:

L:\\.zfs\\snapshot\\snap\\>echo "meh" > myfile.txt
The specified network name is no longer available.

At this point the system panics with the stack above.

A slightly different panic (via rfs3_write) is observed when appending to the existing file, as follows:

echo "meh" >> myfile.txt

> $C
ffffff009e30cb70 vpanic()
ffffff009e30cba0 0xfffffffff79a36a5()
ffffff009e30cc10 dnode_setdirty_sc+0xe9(ffffff15eb54d020, ffffff15ec4ca480, 1)
ffffff009e30ccb0 dbuf_dirty_sc+0x2df(ffffff15c8f4b1d0, ffffff15ec4ca480, 1)
ffffff009e30cd50 dbuf_dirty_sc+0x291(ffffff15c8f4b050, ffffff15ec4ca480, 1)
ffffff009e30cdf0 dbuf_dirty_sc+0x291(ffffff15cbb70e98, ffffff15ec4ca480, 1)
ffffff009e30ce90 dbuf_dirty_sc+0x291(ffffff15cbb70dd8, ffffff15ec4ca480, 1)
ffffff009e30cf30 dbuf_dirty_sc+0x291(ffffff15cbb70d18, ffffff15ec4ca480, 1)
ffffff009e30cfd0 dbuf_dirty_sc+0x291(ffffff15cbb70c58, ffffff15ec4ca480, 1)
ffffff009e30d070 dbuf_dirty_sc+0x291(ffffff15cbb70b98, ffffff15ec4ca480, 1)
ffffff009e30d0e0 dnode_setdirty_sc+0xdd(ffffff15ec821940, ffffff15ec4ca480, 1)
ffffff009e30d180 dbuf_dirty_sc+0x2df(ffffff15d9c0c810, ffffff15ec4ca480, 1)
ffffff009e30d1d0 dbuf_will_dirty_sc+0x75(ffffff15d9c0c810, ffffff15ec4ca480, 1)
ffffff009e30d1f0 dbuf_will_dirty+0x1a(ffffff15d9c0c810, ffffff15ec4ca480)
ffffff009e30d290 dmu_write_uio_dnode+0x90(ffffff15ec821940, ffffff009e30d7b0, 8, ffffff15ec4ca480)
ffffff009e30d2f0 dmu_write_uio_dbuf+0x54(ffffff15da1f33b8, ffffff009e30d7b0, 8, ffffff15ec4ca480)
ffffff009e30d510 zfs_write+0xb76(ffffff15ec6d0040, ffffff009e30d7b0, 10, ffffff15ea5a16f8, ffffff009e30d7e0)
ffffff009e30d590 fop_write+0x5b(ffffff15ec6d0040, ffffff009e30d7b0, 10, ffffff15ea5a16f8, ffffff009e30d7e0)
ffffff009e30d860 rfs3_write+0x4ea(ffffff009e30da00, ffffff009e30d8c0, ffffff15c0387100, ffffff009e30dc00, ffffff15ea5a16f8)
ffffff009e30db80 common_dispatch+0x475(ffffff009e30dc00, ffffff15c1418400, 2, 4, fffffffff841d376, ffffffffc00f1060)
ffffff009e30dba0 rfs_dispatch+0x2d(ffffff009e30dc00, ffffff15c1418400)
ffffff009e30dc80 svc_getreq+0x1c1(ffffff15c1418400, ffffff158cd06de0)
ffffff009e30dcf0 svc_run+0xe0(ffffff15e221e4d8)
ffffff009e30dd30 svc_do_run+0x8e(1)
ffffff009e30de20 nfssys+0xf1(e, fed40fbc)
ffffff009e30dec0 dtrace_systrace_syscall32+0xe4(e, fed40fbc, eeb41e00, e821a420, 1, 0)
ffffff009e30df10 _sys_sysenter_post_swapgs+0x149()

Related issues

Related to illumos gate - Bug #4039: zfs_rename()/zfs_link() needs stronger test for XDEVResolved2013-08-12

Actions
Related to illumos gate - Bug #4642: Checks for ROFS are not sufficient in NFS serverResolved2014-02-27

Actions

History

#1

Updated by Marcel Telka over 5 years ago

  • Status changed from In Progress to Pending RTI
#2

Updated by Electric Monk over 5 years ago

git commit 2144b121c08e0eb676cc6ca4662ebbc9f9c22fe3

Author: Marcel Telka <marcel.telka@nexenta.com>

4638 Panic in ZFS via rfs3_setattr()/rfs3_write(): dirtying snapshot!
Reviewed by: Alek Pinchuk <alek.pinchuk@nexenta.com>
Reviewed by: Ilya Usvyatsky <ilya.usvyatsky@nexenta.com>
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Garrett D'Amore <garrett@damore.org>

#3

Updated by Garrett D'Amore over 5 years ago

  • Status changed from Pending RTI to Resolved
  • % Done changed from 0 to 100
  • Tags deleted (needs-triage)

Also available in: Atom PDF