aboutsummaryrefslogtreecommitdiffstats
path: root/module
Commit message (Collapse)AuthorAgeFilesLines
* Make zfs_immediate_write_sz a module paramaterCyril Plisko2012-10-111-2/+7
| | | | | | | | zfs_immediate_write_sz variable is a tunable, but lacks proper module_param() instrumentation. Signed-off-by: Brian Behlendorf <[email protected]> Closes #1032
* txg is spelled as tgx in placesCyril Plisko2012-10-111-5/+5
| | | | | | | | | Term 'transaction group' is commonly abbreviated as txg in ZFS sources. There are some places (Linux specific MODULE_PARAM_DESC() macros) where it is incorrectly spelled as 'tgx'. Signed-off-by: Brian Behlendorf <[email protected]> Closes #1030
* Switch KM_SLEEP to KM_PUSHPAGEMassimo Maggi2012-10-081-1/+1
| | | | | | | | Prevent snapshot_check to initiate I/O during memory allocation. Signed-off-by: Massimo Maggi <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #1023
* Set default zvol elevator to noopBrian Behlendorf2012-10-051-0/+10
| | | | | | | | | | | | | | | | It doesn't make sense for a zvol to use the default system I/O scheduler because it is a virtual device. Therefore, we change the default scheduler to 'noop' for zvols provided that the elevator_change() function is available. This interface has been available since Linux 2.6.36 and appears in the RHEL 6.x kernels. We deliberately do not implement the method for older kernels because it was racy and could result in system crashes. It's better to simply manually tune the scheduler for these kernels. Signed-off-by: Brian Behlendorf <[email protected]> Closes #1017
* Align DISCARD requests on zvols.Etienne Dechamps2012-10-041-9/+18
| | | | | | | | | | | | | | | | | | Currently, when processing DISCARD requests, zvol_discard() calls dmu_free_long_range() with the precise offset and size of the request. Unfortunately, this is not optimal for requests that are not aligned to the zvol block boundaries. Indeed, in the case of an unaligned range, dnode_free_range() will zero out the unaligned parts. Not only is this useless since we are not freeing any space by doing so, it is also slow because it translates to a read-modify-write operation. This patch fixes the issue by rounding up the discard start offset to the next volume block boundary, and rounding down the discard end offset to the previous volume block boundary. Signed-off-by: Brian Behlendorf <[email protected]> Closes #1010
* Switch KM_SLEEP to KM_PUSHPAGEChris Dunlop2012-10-041-1/+1
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fc for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Chris Dunlop <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #1002
* Illumos #3100: zvol rename fails with EBUSY when dirty.Matthew Ahrens2012-10-035-30/+26
| | | | | | | | | | | | | | | | | illumos/illumos-gate@2e2c135528b3edfe9aaf67d1f004dc0202fa1a54 Illumos changeset: 13780:6da32a929222 3100 zvol rename fails with EBUSY when dirty Reviewed by: Christopher Siden <[email protected]> Reviewed by: Adam H. Leventhal <[email protected]> Reviewed by: George Wilson <[email protected]> Reviewed by: Garrett D'Amore <[email protected]> Approved by: Eric Schrock <[email protected]> Ported-by: Etienne Dechamps <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #995
* Illumos #3129, #3130George Wilson2012-10-032-5/+17
| | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@d6afdce20f8481c95471dd821bc8ec0dbde66213 Illumos changeset: 13794:7c5e0e746b2c 3129 'zpool reopen' restarts resilvers 3130 ztest failure: Assertion failed: 0 == dmu_objset_destroy(name, B_FALSE) (0x0 == 0x10) Reviewed by: Eric Schrock <[email protected]> Reviewed by: Matt Ahrens <[email protected]> Reviewed by: Christopher Siden <[email protected]> Reviewed by: Adam Leventhal <[email protected]> Approved by: Dan McDonald <[email protected]> References: https://www.illumos.org/issues/3129 https://www.illumos.org/issues/3130 Ported by: Etienne Dechamps <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #994
* Modify vdev_elevator_switch() to use elevator_change()Brian Behlendorf2012-10-031-18/+23
| | | | | | | | | | | As of Linux 2.6.36 an elevator_change() interface was added. This commit updates vdev_elevator_switch() to use this interface when available, otherwise it falls back to the usermodehelper method. Original-patch-by: foobarz <sysop@xeon.(none)> Signed-off-by: Brian Behlendorf <[email protected]> Closes #906
* Implement .commit_metadata hook for NFS exportCyril Plisko2012-10-031-1/+21
| | | | | | | | | | | In order to implement synchronous NFS metadata semantics ZFS needs to provide the .commit_metadata hook. All it takes there is to make sure changes are committed to ZIL. Fortunately zfs_fsync() does just that, so simply calling it from zpl_commit_metadata() does the trick. Signed-off-by: Brian Behlendorf <[email protected]> Closes #969
* zvol_probe should return NULL when the device isn't found.Chris Wedgwood2012-10-031-1/+1
| | | | | | | | | | | | | Previously we returned ERR_PTR(-ENOENT) which the rest of the kernel doesn't expect and as such we can oops. Signed-off-by: Chris Wedgwood <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #949 Closes #931 Closes #789 Closes #743 Closes #730
* Illumos #2703: add mechanism to report ZFS send progressBill Pijewski2012-09-193-123/+183
| | | | | | | | | | | | | Reviewed by: Matt Ahrens <[email protected]> Reviewed by: Robert Mustacchi <[email protected]> Reviewed by: Richard Lowe <[email protected]> Approved by: Eric Schrock <[email protected]> References: https://www.illumos.org/issues/2703 Ported by: Martin Matuska <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]>
* Illumos #1948: zpool list should show more detailed pool infoChris Siden2012-09-1910-16/+85
| | | | | | | | | | | | | | | | | | Reviewed by: Adam Leventhal <[email protected]> Reviewed by: Matt Ahrens <[email protected]> Reviewed by: Eric Schrock <[email protected]> Reviewed by: Richard Lowe <[email protected]> Reviewed by: Albert Lee <[email protected]> Reviewed by: Dan McDonald <[email protected]> Reviewed by: Garrett D'Amore <[email protected]> Approved by: Eric Schrock <[email protected]> References: https://www.illumos.org/issues/1948 Ported by: Martin Matuska <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #685
* Switch KM_SLEEP to KM_PUSHPAGEBrian Behlendorf2012-09-191-3/+3
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Brian Behlendorf <[email protected]> Issue #973
* Switch KM_SLEEP to KM_PUSHPAGEBrian Behlendorf2012-09-171-1/+1
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Brian Behlendorf <[email protected]> Issue #917
* ZFS replay transaction error 5Cyril Plisko2012-09-171-8/+7
| | | | | | | | | | | | | | | | | | | | When zfs_replay_write() replays TX_WRITE records from ZIL it calls zpl_write_common() to perform the actual write. zpl_write_common() returns the number of bytes written (similar to write() system call) or an (negative) error. However, the code expects the positive return value to be a residual counter. Thus when zpl_write_common() successfully completes it is mistakenly considered to be a partial write and the error code delivered further. At this point the ZIL processing is aborted with famous "ZFS replay transaction error 5" error message given to the message buffer. The fix is to compare the zpl_write_commmon() return value with the buffer size and flag error only when they disagree. Signed-off-by: Cyril Plisko <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #933
* Clear PG_writeback for sync I/O error caseBrian Behlendorf2012-09-141-0/+9
| | | | | | | | | | | | | | | Commit 2b2861362f7dd09cc3167df8fddb6e2cb475018a accidentally introduced this issue by only conditionally registering the commit callback in the async case. The error handing code for the dmu_tx_assign() failure case relied on there always being a registered commit callback to clear the PG_writeback bit. Since that is no longer strictly true for the synchronous case we must explicitly invoke the callback. Signed-off-by: Brian Behlendorf <[email protected]> Closes #961
* Move iput() after zfs_inode_update()Brian Behlendorf2012-09-121-2/+2
| | | | | | | | | | | | | | | When replaying an unlink/remove operation via zfs_rmdir() the object being removed will be instantiated by a call to zfs_dirent_lock(). This means that there is a single reference protecting the object. Right before the call to zfs_inode_update() this reference is dropped which may cause the object to be destroyed. This will result in a NULL dereference as shown by the stack trace is issue #782. This likely isn't an issue during normal operation because there is always an additional reference held on the object by the VFS. Signed-off-by: Brian Behlendorf <[email protected]> Closes #782
* Remove zvol device nodeBrian Behlendorf2012-09-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The 'zfs destroy' changes in 330d06f disrupted how zvol devices get removed on ZoL. However, it basically boils down to the fact that we are no longer reliably calling zvol_remove_minor() via zfs_ioc_destroy_snaps(). Therefore we add the missing call and handle things similarly to the existing zfs_unmount_snap() case. Ideally we would check if this is of type DMU_OST_ZFS or DMU_OST_ZVOL and just do the right thing as in zfs_ioc_destroy(). However, it looks like it would be fairly expensive to get the type, and it's harmless to simply attempt the umount and minor removal. This is also an issue in the latest FreeBSD and Illumos code. It was being tracked under the following issue, and we may want to refresh our code when they settle on what they want to do about it upstream. https://www.illumos.org/issues/3170 Signed-off-by: Brian Behlendorf <[email protected]> Issue #903
* Make ZFS filesystem id persistent across different machinesCyril Plisko2012-09-061-2/+4
| | | | | | | | | Use ZFS dataset fsid guid as a unique file system id, similar to what is done on Illumos/OpenSolaris. Signed-off-by: Cyril Plisko <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #888
* Disable page allocation warnings for ARC buffersBrian Behlendorf2012-09-061-2/+3
| | | | | | | | | | | | | | | | | | | | | Buffers for the ARC are normally backed by the SPL virtual slab. However, if memory is low, AND no slab objects are available, AND a new slab cannot be quickly constructed a new emergency object will be directly allocated. These objects can be as large as order 5 on a system with 4k pages. And because they are allocated with KM_PUSHPAGE, to avoid a potential deadlock, they are not allowed to initiate I/O to satisfy the allocation. This can result in the occasional allocation failure. However, since these allocations are allowed to block and perform operations such as memory compaction they will eventually succeed. Since this is not unexpected (just unlikely) behavior this patch disables the warning for the allocation failure. Signed-off-by: Brian Behlendorf <[email protected]> Issue #465
* Switch KM_SLEEP to KM_PUSHPAGEBrian Behlendorf2012-09-052-3/+3
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Brian Behlendorf <[email protected]> Issue #917
* Switch KM_SLEEP to KM_PUSHPAGEBrian Behlendorf2012-09-041-2/+2
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Brian Behlendorf <[email protected]> Issue #917
* Switch KM_SLEEP to KM_PUSHPAGEBrian Behlendorf2012-09-041-1/+1
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Brian Behlendorf <[email protected]> Issue #917
* Switch KM_SLEEP to KM_PUSHPAGEChris Dunlop2012-09-022-6/+6
| | | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Chris Dunlop <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #917
* Switch KM_SLEEP to KM_PUSHPAGEBrian Behlendorf2012-08-311-2/+2
| | | | | | | | | | | | | This warning indicates the incorrect use of KM_SLEEP in a call path which must use KM_PUSHPAGE to avoid deadlocking in direct reclaim. See commit b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details. SPL: Fixing allocation for task txg_sync (6093) which used GFP flags 0x297bda7c with PF_NOFS set Signed-off-by: Brian Behlendorf <[email protected]> Issue #917
* Clear PG_writeback after zil_commit() for sync I/OBrian Behlendorf2012-08-301-3/+8
| | | | | | | | | | | | | | | | | When writing via ->writepage() the writeback bit was always cleared as part of the txg commit callback. However, when the I/O is also being written synchronsously to the zil we can immediately clear this bit. There is no need to wait for the subsequent TXG sync since the data is already safe on stable storage. This has been observed to reduce the msync(2) delay from up to 5 seconds down 10s of miliseconds. One workload which is expected to benefit from this are the intermittent samba hands described in issue #700. Signed-off-by: Brian Behlendorf <[email protected]> Closes #700 Closes #907
* Switch KM_SLEEP to KM_PUSHPAGERichard Yao2012-08-2741-170/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Differences between how paging is done on Solaris and Linux can cause deadlocks if KM_SLEEP is used in any the following contexts. * The txg_sync thread * The zvol write/discard threads * The zpl_putpage() VFS callback This is because KM_SLEEP will allow for direct reclaim which may result in the VM calling back in to the filesystem or block layer to write out pages. If a lock is held over this operation the potential exists to deadlock the system. To ensure forward progress all memory allocations in these contexts must us KM_PUSHPAGE which disables performing any I/O to accomplish the memory allocation. Previously, this behavior was acheived by setting PF_MEMALLOC on the thread. However, that resulted in unexpected side effects such as the exhaustion of pages in ZONE_DMA. This approach touchs more of the zfs code, but it is more consistent with the right way to handle these cases under Linux. This is patch lays the ground work for being able to safely revert the following commits which used PF_MEMALLOC: 21ade34 Disable direct reclaim for z_wr_* threads cfc9a5c Fix zpl_writepage() deadlock eec8164 Fix ASSERTION(!dsl_pool_sync_context(tx->tx_pool)) Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #726
* mzap_upgrade() must use kmem_alloc()Brian Behlendorf2012-08-271-3/+3
| | | | | | | | | | These allocations in mzap_update() used to be kmem_alloc() but were changed to vmem_alloc() due to the size of the allocation. However, since it turns out this function may be called in the context of the txg_sync thread they must be changed back to use a kmem_alloc() to ensure the KM_PUSHPAGE flag is honored. Signed-off-by: Brian Behlendorf <[email protected]>
* Annotate KM_PUSHPAGE call paths with PF_NOFSBrian Behlendorf2012-08-273-5/+42
| | | | | | | | | | | | | | | | | The txg_sync(), zfs_putpage(), zvol_write(), and zvol_discard() call paths must only use KM_PUSHPAGE to avoid potential deadlocks during direct reclaim. This patch annotates these call paths so any accidental use of KM_SLEEP will be quickly detected. In the interest of stability if debugging is disabled the offending allocation will have its GFP flags automatically corrected. When debugging is enabled any misuse will be treated as a fatal error. This patch is entirely for debugging. We should be careful to NOT become dependant on it fixing up the incorrect allocations. Signed-off-by: Brian Behlendorf <[email protected]>
* Pre-allocate vdev I/O buffersBrian Behlendorf2012-08-272-2/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vdev queue layer may require a small number of buffers when attempting to create aggregate I/O requests. Rather than attempting to allocate them from the global zio buffers, which is slow under memory pressure, it makes sense to pre-allocate them because... 1) These buffers are short lived. They are only required for the life of a single I/O at which point they can be used by the next I/O. 2) The maximum number of concurrent buffers needed by a vdev is small. It's roughly limited by the zfs_vdev_max_pending tunable which defaults to 10. By keeping a small list of these buffer per-vdev we can ensure one is always available when we need it. This significantly reduces contention on the vq->vq_lock, because we no longer need to perform a slow allocation under this lock. This is particularly important when memory is already low on the system. It would probably be wise to extend the use of these buffers beyond aggregate I/O and in to the raidz implementation. The inability to quickly allocate buffer for the parity stripes could result in similiar problems. Signed-off-by: Brian Behlendorf <[email protected]>
* Revert Disable direct reclaim for z_wr_* threadsRichard Yao2012-08-271-6/+3
| | | | | | | | | | | | | | This commit used PF_MEMALLOC to prevent a memory reclaim deadlock. However, commit 49be0ccf1fdc2ce852271d4d2f8b7a9c2c4be6db eliminated the invocation of __cv_init(), which was the cause of the deadlock. PF_MEMALLOC has the side effect of permitting pages from ZONE_DMA to be allocated. The use of PF_MEMALLOC was found to cause stability problems when doing swap on zvols. Since this technique is known to cause problems and no longer fixes anything, we revert it. Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #726
* Revert Fix zpl_writepage() deadlockRichard Yao2012-08-271-14/+1
| | | | | | | | | | | | | | | | | | | | | The commit, cfc9a5c88f91f7b4d606fce89505e1f404691ea5, to fix deadlocks in zpl_writepage() relied on PF_MEMALLOC. That had the effect of disabling the direct reclaim path on all allocations originating from calls to this function, but it failed to address the actual cause of those deadlocks. This led to the same deadlocks being observed with swap on zvols, but not with swap on the loop device, which exercises this code. The use of PF_MEMALLOC also had the side effect of permitting allocations to be made from ZONE_DMA in instances that did not require it. This contributes to the possibility of panics caused by depletion of pages from ZONE_DMA. As such, we revert this patch in favor of a proper fix for both issues. Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #726
* Revert Fix ASSERTION(!dsl_pool_sync_context(tx->tx_pool))Richard Yao2012-08-271-13/+0
| | | | | | | | | | | Commit eec8164771bee067c3cd55ed0a16dadeeba276de worked around an issue involving direct reclaim through the use of PF_MEMALLOC. Since we are reworking thing to use KM_PUSHPAGE so that swap works, we revert this patch in favor of the use of KM_PUSHPAGE in the affected areas. Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #726
* rmdir(2) should return ENOTEMPTYBrian Behlendorf2012-08-261-3/+3
| | | | | | | | | | | | | | | Under Solaris the behavior for rmdir(2) is to return EEXIST when a directory still contains entries. However, on Linux ENOTEMPTY is the expected return value with EEXIST being technically allowed. According to rmdir(2): ENOTEMPTY pathname contains entries other than . and .. ; or, pathname has .. as its final component. POSIX.1-2001 also allows EEXIST for this condition. Signed-off-by: Brian Behlendorf <[email protected]> Closes #895
* Illumos #3085: zfs diff panics, then panics in a loop on bootingChristopher Siden2012-08-251-4/+5
| | | | | | | | | | | Reviewed by: Matt Ahrens <[email protected]> Approved by: Richard Lowe <[email protected]> References: https://www.illumos.org/issues/3085 Ported by: Martin Matuska <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]>
* Illumos #2901: zfs receive fails for exabyte sparse filesSimon Klinkert2012-08-251-0/+3
| | | | | | | | | | | Reviewed by: Matthew Ahrens <[email protected]> Approved by: Dan McDonald <[email protected]> References: https://www.illumos.org/issues/2901 Ported by: Martin Matuska <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]>
* Drop spill buffer referenceJaven Wu2012-08-251-2/+22
| | | | | | | | | | | | | | | | | | | When calling sa_update() and friends it is possible that a spill buffer will be needed to accomidate the update. When this happens a hold is taken on the new dbuf and that hold must be released before calling dmu_tx_commit(). Failing to release the hold will cause a copy of the dbuf to be made in dbuf_sync_leaf(). This is done to ensure further updates to the dbuf never sneak in to the syncing txg. This could be left to the sa_update() caller. But then the caller would need to be aware of this internal SA implementation detail. It is therefore preferable to handle this all internally in the SA implementation. Signed-off-by: Brian Behlendorf <[email protected]> Closes #503 Closes #513
* Revert "Use SA_HDL_PRIVATE for SA xattrs"Brian Behlendorf2012-08-251-28/+5
| | | | | | | | | | | | This reverts commit ec2626ad3f695a2ced3946c4197ef64cbcac4959 which caused consistency problems between the shared and private handles. Reverting this change should resolve issues #709 and #727. It will also reintroduce an arc_anon memory leak which is addressed by the next commit. Signed-off-by: Brian Behlendorf <[email protected]> Closes #709 Closes #727
* Wrap smp_processor_id in kpreempt_[dis|en]ablePrakash Surya2012-08-242-2/+18
| | | | | | | | | | | | | After surveying the code, the few places where smp_processor_id is used were deemed to be safe to use with a preempt enabled kernel. As such, no core logic had to be changed. These smp_processor_id call sites are simply are wrapped in kpreempt_disable and kpreempt_enabled to prevent the Linux kernel from emitting scary warnings. Signed-off-by: Prakash Surya <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Signed-off-by: Richard Yao <[email protected]> Issue #83
* Export dmu_buf_rele() symbolBrian Behlendorf2012-08-141-0/+1
| | | | | | | | | While I'd like to remove the various pragmas in module/zfs/dbuf.c. There are consumers such as Lustre which still depend on dmu_buf_* versions of the symbols. Until all consumers can be converted to use only the dbuf_* names leave this symbol exported. Signed-off-by: Brian Behlendorf <[email protected]>
* Suppress 'zfs_sb_create' memory warningBrian Behlendorf2012-08-101-1/+1
| | | | | | | | | | When mutex debugging is enabled in your kernel the increased size of the mutex structures can push the zfs_sb_t type beyond the 8k warning threshold. This isn't harmful so we suppress the warning for this case. Signed-off-by: Brian Behlendorf <[email protected]> Closes #628
* Export dbuf_* symbolsBrian Behlendorf2012-08-101-1/+33
| | | | | | | | | | | | | Export these symbols so they may be used by other ZFS consumers besides the ZPL. Remove three stale prototype definites from dbuf.h. The actual implementations of these functions were removed/renamed long ago. It would be good in the long term to remove the existing pragmas we inherited from Solaris and simply use the dbuf_* names. Signed-off-by: Brian Behlendorf <[email protected]>
* Illumos #1693: persistent 'comment' field for a zpoolDan McDonald2012-08-083-1/+54
| | | | | | | | | | | | | Reviewed by: George Wilson <[email protected]> Reviewed by: Eric Schrock <[email protected]> Approved by: Richard Lowe <[email protected]> References: https://www.illumos.org/issues/1693 Ported by: Martin Matuska <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #678
* Set zvol discard_granularity to the volblocksize.Etienne Dechamps2012-08-071-0/+1
| | | | | | | | | | | | | | | | | | Currently, zvols have a discard granularity set to 0, which suggests to the upper layer that discard requests of arbirarily small size and alignment can be made efficiently. In practice however, ZFS does not handle unaligned discard requests efficiently: indeed, it is unable to free a part of a block. It will write zeros to the specified range instead, which is both useless and inefficient (see dnode_free_range). With this patch, zvol block devices expose volblocksize as their discard granularity, so the upper layer is aware that it's not supposed to send discard requests smaller than volblocksize. Signed-off-by: Brian Behlendorf <[email protected]> Closes #862
* Limit the number of blocks to discard at once.Etienne Dechamps2012-07-311-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The number of blocks that can be discarded in one BLKDISCARD ioctl on a zvol is currently unlimited. Some applications, such as mkfs, discard the whole volume at once and they use the maximum possible discard size to do that. As a result, several gigabytes discard requests are not uncommon. Unfortunately, if a large amount of data is allocated in the zvol, ZFS can be quite slow to process discard requests. This is especially true if the volblocksize is low (e.g. the 8K default). As a result, very large discard requests can take a very long time (seconds to minutes under heavy load) to complete. This can cause a number of problems, most notably if the zvol is accessed remotely (e.g. via iSCSI), in which case the client has a high probability of timing out on the request. This patch solves the issue by adding a new tunable module parameter: zvol_max_discard_blocks. This indicates the maximum possible range, in zvol blocks, of one discard operation. It is set by default to 16384 blocks, which appears to be a good tradeoff. Using the default volblocksize of 8K this is equivalent to 128 MB. When using the maximum volblocksize of 128K this is equivalent to 2 GB. Signed-off-by: Brian Behlendorf <[email protected]> Closes #858
* Illumos #1644, #1645, #1646, #1647, #1708Matthew Ahrens2012-07-3110-127/+594
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1644 add ZFS "clones" property 1645 add ZFS "written" and "written@..." properties 1646 "zfs send" should estimate size of stream 1647 "zfs destroy" should determine space reclaimed by destroying multiple snapshots 1708 adjust size of zpool history data References: https://www.illumos.org/issues/1644 https://www.illumos.org/issues/1645 https://www.illumos.org/issues/1646 https://www.illumos.org/issues/1647 https://www.illumos.org/issues/1708 This commit modifies the user to kernel space ioctl ABI. Extra care should be taken when updating to ensure both the kernel modules and utilities are updated. This change has reordered all of the new ioctl()s to the end of the list. This should help minimize this issue in the future. Reviewed by: Richard Lowe <[email protected]> Reviewed by: George Wilson <[email protected]> Reviewed by: Albert Lee <[email protected]> Approved by: Garrett D'Amore <[email protected]> Ported by: Martin Matuska <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #826 Closes #664
* Add script for builtin module building.Etienne Dechamps2012-07-267-31/+18
| | | | | | | | | | | | | | | | | This commit introduces a "copy-builtin" script designed to prepare a kernel source tree for building ZFS as a builtin module. The script makes a full copy of all needed files, thus making the kernel source tree fully independent of the zfs source package. To achieve that, some compilation flags (-include, -I) have been moved to module/Makefile. This Makefile is only used when compiling external modules; when compiling builtin modules, a Kbuild file generated by the configure-builtin script is used instead. This makes sure Makefiles inside the kernel source tree does not contain references to the zfs source package. Signed-off-by: Brian Behlendorf <[email protected]> Issue #851
* Linux 3.5 compat, end_writeback() changed to clear_inode()Richard Yao2012-07-231-5/+10
| | | | | | | | | | | | | | | | The end_writeback() function was changed by moving the call to inode_sync_wait() earlier in to evict(). This effecitvely changes the ordering of the sync but it does not impact the details of the zfs implementation. However, as part of this change end_writeback() was renamed to clear_inode() to reflect the new semantics. This change does impact us and clear_inode() now maps to end_writeback() for kernels prior to 3.5. Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #784
* Linux 3.5 compat, iops->truncate_range() removedRichard Yao2012-07-231-0/+4
| | | | | | | | | The vmtruncate_range() support has been removed from the kernel in favor of using the fallocate method in the file_operations table. Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #784
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 23:15:38 +0000