aboutsummaryrefslogtreecommitdiffstats
path: root/module
Commit message (Collapse)AuthorAgeFilesLines
* Disable direct reclaim for z_wr_* threadsBrian Behlendorf2011-05-061-3/+6
| | | | | | | | | | | | | | | | | | The direct reclaim path in the z_wr_* threads must be disabled to ensure forward progress is always maintained for txg processing. This ensures that a txg will never get stuck waiting on itself because it entered the following memory reclaim callpath. ->prune_icache()->dispose_list()->zpl_clear_inode()->zfs_inactive() ->dmu_tx_assign()->dmu_tx_wait()->tgx_wait_open() It would be preferable to target this exact code path but the kernel offers no way to do this without custom patches. To avoid this we are forced to disable all reclaim for these threads. It should not be necessary to do this for other other z_* threads because they will not hold a txg open. Closes #232
* Handle NULL in nfsd .fsync() hookBrian Behlendorf2011-05-061-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | How nfsd handles .fsync() has been changed a couple of times in the recent kernels. But basically there are three cases we need to consider. Linux 2.6.12 - 2.6.33 * The .fsync() hook takes 3 arguments * The nfsd will call .fsync() with a NULL file struct pointer. Linux 2.6.34 * The .fsync() hook takes 3 arguments * The nfsd no longer calls .fsync() but instead used sync_inode() Linux 2.6.35 - 2.6.x * The .fsync() hook takes 2 arguments * The nfsd no longer calls .fsync() but instead used sync_inode() For once it looks like we've gotten lucky. The first two cases can actually be collased in to one if we stop using the file struct pointer entirely. Since the dentry is still passed in both cases this is possible. The last case can then be safely handled by unconditionally using the dentry in the file struct pointer now that we know the nfsd caller has been removed. Closes #230
* Use vmem_alloc() for zfs_ioc_pool_get_history()Brian Behlendorf2011-05-061-2/+2
| | | | | | | | The default buffer size when requesting history is 128k. This is far to large for a kmem_alloc() so instead use the slower vmem_alloc(). This path has no performance concerns and the buffer is immediately free'd after its contents are copied to the user space buffer.
* Add missing ZFS tunablesBrian Behlendorf2011-05-0416-41/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds module options for all existing zfs tunables. Ideally the average user should never need to modify any of these values. However, in practice sometimes you do need to tweak these values for one reason or another. In those cases it's nice not to have to resort to rebuilding from source. All tunables are visable to modinfo and the list is as follows: $ modinfo module/zfs/zfs.ko filename: module/zfs/zfs.ko license: CDDL author: Sun Microsystems/Oracle, Lawrence Livermore National Laboratory description: ZFS srcversion: 8EAB1D71DACE05B5AA61567 depends: spl,znvpair,zcommon,zunicode,zavl vermagic: 2.6.32-131.0.5.el6.x86_64 SMP mod_unload modversions parm: zvol_major:Major number for zvol device (uint) parm: zvol_threads:Number of threads for zvol device (uint) parm: zio_injection_enabled:Enable fault injection (int) parm: zio_bulk_flags:Additional flags to pass to bulk buffers (int) parm: zio_delay_max:Max zio millisec delay before posting event (int) parm: zio_requeue_io_start_cut_in_line:Prioritize requeued I/O (bool) parm: zil_replay_disable:Disable intent logging replay (int) parm: zfs_nocacheflush:Disable cache flushes (bool) parm: zfs_read_chunk_size:Bytes to read per chunk (long) parm: zfs_vdev_max_pending:Max pending per-vdev I/Os (int) parm: zfs_vdev_min_pending:Min pending per-vdev I/Os (int) parm: zfs_vdev_aggregation_limit:Max vdev I/O aggregation size (int) parm: zfs_vdev_time_shift:Deadline time shift for vdev I/O (int) parm: zfs_vdev_ramp_rate:Exponential I/O issue ramp-up rate (int) parm: zfs_vdev_read_gap_limit:Aggregate read I/O over gap (int) parm: zfs_vdev_write_gap_limit:Aggregate write I/O over gap (int) parm: zfs_vdev_scheduler:I/O scheduler (charp) parm: zfs_vdev_cache_max:Inflate reads small than max (int) parm: zfs_vdev_cache_size:Total size of the per-disk cache (int) parm: zfs_vdev_cache_bshift:Shift size to inflate reads too (int) parm: zfs_scrub_limit:Max scrub/resilver I/O per leaf vdev (int) parm: zfs_recover:Set to attempt to recover from fatal errors (int) parm: spa_config_path:SPA config file (/etc/zfs/zpool.cache) (charp) parm: zfs_zevent_len_max:Max event queue length (int) parm: zfs_zevent_cols:Max event column width (int) parm: zfs_zevent_console:Log events to the console (int) parm: zfs_top_maxinflight:Max I/Os per top-level (int) parm: zfs_resilver_delay:Number of ticks to delay resilver (int) parm: zfs_scrub_delay:Number of ticks to delay scrub (int) parm: zfs_scan_idle:Idle window in clock ticks (int) parm: zfs_scan_min_time_ms:Min millisecs to scrub per txg (int) parm: zfs_free_min_time_ms:Min millisecs to free per txg (int) parm: zfs_resilver_min_time_ms:Min millisecs to resilver per txg (int) parm: zfs_no_scrub_io:Set to disable scrub I/O (bool) parm: zfs_no_scrub_prefetch:Set to disable scrub prefetching (bool) parm: zfs_txg_timeout:Max seconds worth of delta per txg (int) parm: zfs_no_write_throttle:Disable write throttling (int) parm: zfs_write_limit_shift:log2(fraction of memory) per txg (int) parm: zfs_txg_synctime_ms:Target milliseconds between tgx sync (int) parm: zfs_write_limit_min:Min tgx write limit (ulong) parm: zfs_write_limit_max:Max tgx write limit (ulong) parm: zfs_write_limit_inflated:Inflated tgx write limit (ulong) parm: zfs_write_limit_override:Override tgx write limit (ulong) parm: zfs_prefetch_disable:Disable all ZFS prefetching (int) parm: zfetch_max_streams:Max number of streams per zfetch (uint) parm: zfetch_min_sec_reap:Min time before stream reclaim (uint) parm: zfetch_block_cap:Max number of blocks to fetch at a time (uint) parm: zfetch_array_rd_sz:Number of bytes in a array_read (ulong) parm: zfs_pd_blks_max:Max number of blocks to prefetch (int) parm: zfs_dedup_prefetch:Enable prefetching dedup-ed blks (int) parm: zfs_arc_min:Min arc size (ulong) parm: zfs_arc_max:Max arc size (ulong) parm: zfs_arc_meta_limit:Meta limit for arc size (ulong) parm: zfs_arc_reduce_dnlc_percent:Meta reclaim percentage (int) parm: zfs_arc_grow_retry:Seconds before growing arc size (int) parm: zfs_arc_shrink_shift:log2(fraction of arc to reclaim) (int) parm: zfs_arc_p_min_shift:arc_c shift to calc min/max arc_p (int)
* Fully update inode when createdBrian Behlendorf2011-05-021-2/+1
| | | | | | | | | | | | | | When a new znode/inode pair is created both the znode and the inode should be immediately updated to the correct values. This was done for the znode and for most of the values in the inode, but not all of them. This normally wasn't a problem because most subsequent operations would cause the inode to be immediately updated. This change ensures the inode is now fully updated before it is inserted in to the inode hash. Closes #116 Closes #146 Closes #164
* Fix 'zfs set volsize=N pool/dataset'Brian Behlendorf2011-05-021-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a kernel panic which would occur when resizing a dataset which was not open. The objset_t stored in the zvol_state_t will be set to NULL when the block device is closed. To avoid this issue we pass the correct objset_t as the third arg. The code has also been updated to correctly notify the kernel when the block device capacity changes. For 2.6.28 and newer kernels the capacity change will be immediately detected. For earlier kernels the capacity change will be detected when the device is next opened. This is a known limitation of older kernels. Online ext3 resize test case passes on 2.6.28+ kernels: $ dd if=/dev/zero of=/tmp/zvol bs=1M count=1 seek=1023 $ zpool create tank /tmp/zvol $ zfs create -V 500M tank/zd0 $ mkfs.ext3 /dev/zd0 $ mkdir /mnt/zd0 $ mount /dev/zd0 /mnt/zd0 $ df -h /mnt/zd0 $ zfs set volsize=800M tank/zd0 $ resize2fs /dev/zd0 $ df -h /mnt/zd0 Original-patch-by: Fajar A. Nugraha <[email protected]> Closes #68 Closes #84
* Implemented NFS export_operations.Gunnar Beutner2011-04-294-11/+123
| | | | | Implemented the required NFS operations for exporting ZFS datasets using the in-kernel NFS daemon.
* Suppress 'vdev_metaslab_init' memory warningBrian Behlendorf2011-04-271-1/+1
| | | | | | | The vdev_metaslab_init() function has been observed to allocate larger than 8k chunks. However, they are not much larger than 8k and it does this infrequently so it is allowed and the warning is supressed.
* Conserve stack in dsl_scan_visit()Brian Behlendorf2011-04-261-10/+15
| | | | | | | | | | | | | | The dsl_scan_visit() function is a little heavy weight taking 464 bytes on the stack. This can be easily reduced for little cost by moving zap_cursor_t and zap_attribute_t off the stack and on to the heap. After this change dsl_scan_visit() has been reduced in size by 320 bytes. This change was made to reduce stack usage in the dsl_scan_sync() callpath which is recursive and has been observed to overflow the stack. Issue #174
* Conserve stack in dsl_scan_visitbp()Brian Behlendorf2011-04-261-5/+12
| | | | | | | | | | | This function is called recursively so everything possible must be done to limit its stack consumption. The dprintf_bp() debugging function adds 30 bytes of local variables to the function we cannot afford. By commenting out this debugging we save 30 bytes per recursion and depths of 13 are not uncommon. This yeilds a total stack saving of 390 bytes on our 8k stack. Issue #174
* Conserve stack in dsl_scan_visitbp()Brian Behlendorf2011-04-261-2/+2
| | | | | | | | | | | | | The recursive call chain dsl_scan_visitbp() -> dsl_scan_recurse() -> dsl_scan_visitdnode() -> dsl_scan_visitbp has been observed to consume considerable stack resulting in a stack overflow (>8k). The cleanest way I see to fix this with minimal impact to the existing flow of code, and with the fewest performance concerns, is to always inline dsl_scan_recurse() and dsl_scan_visitdnode(). While this will increase the function size of dsl_scan_visitbp(), by 4660 bytes, it also reduces the stack requirements by removing the function call overhead. Issue #174
* Fix zvol deadlockBrian Behlendorf2011-04-261-1/+2
| | | | | | | | | | | | It's possible for a zvol_write thread to enter direct memory reclaim while holding open a transaction group. This results in the system attempting to write out data to the disk to free memory. Unfortunately, this can't succeed because the the thread doing reclaim is holding open the txg which must be closed to be synced to disk. To prevent this the offending allocation is marked KM_PUSHPAGE which will prevent it from attempting writeback. Closes #191
* Fix spurious -EFAULT when setting I/O schedulerBrian Behlendorf2011-04-221-17/+12
| | | | | | | | | | | | Occasionally we would see an -EFAULT returned when setting the I/O scheduler on a vdev. This was caused an improperly formatted user mode helper command. This commit restructures the command to something simpler, allocates space for it dynamically to save stack, and removes the retry logic which is no longer needed. Closes #169
* Enforce ARC meta-data limitsBrian Behlendorf2011-04-211-2/+15
| | | | | | | | | | | | | | | This change ensures the ARC meta-data limits are enforced. Without this enforcement meta-data can grow to consume all of the ARC cache pushing out data and hurting performance. The cache is aggressively reclaimed but this is a soft and not a hard limit. The cache may exceed the set limit briefly before being brought under control. By default 25% of the ARC capacity can be used for meta-data. This limit can be tuned by setting the 'zfs_arc_meta_limit' module option. Once this limit is exceeded meta-data reclaim will occur in 3 percent chunks, or may be tuned using 'arc_reduce_dnlc_percent'. Closes #193
* Fixed a use-after-free bug in zfs_zget().Gunnar Beutner2011-04-211-1/+23
| | | | | | | | | | Fixed a bug where zfs_zget could access a stale znode pointer when the inode had already been removed from the inode cache via iput -> iput_final -> ... -> zfs_zinactive but the corresponding SA handle was still alive. Signed-off-by: Brian Behlendorf <[email protected]> Closes #180
* Suppress 'zfs receive' memory warningBrian Behlendorf2011-04-201-1/+1
| | | | | | | | | | As part of zfs_ioc_recv() a zfs_cmd_t is allocated in the kernel which is 17808 bytes in size. This sort of thing in general should be avoided. However, since this should be an infrequent event for now we allow it and simply suppress the warning with the KM_NODEBUG flag. This can be revisited latter if/when it becomes an issue. Closes #178
* Truncate the xattr znode when updating existing attributes.Gunnar Beutner2011-04-191-1/+7
| | | | | | | | If the attribute's new value was shorter than the old one the old code would leave parts of the old value in the xattr znode. Signed-off-by: Brian Behlendorf <[email protected]> Closes #203
* Added missing initialization for va.va_dentry in zfs_get_xattrdir.Gunnar Beutner2011-04-191-0/+1
| | | | | | | | | | | | Without this we may mistakenly believe we have a dentry and try to d_instantiate() it. This will result in the following BUG. It's important to note that while the xattr directory has an inode assoicated with it we never create a dentry for it. kernel BUG at fs/dcache.c:1418! Signed-off-by: Brian Behlendorf <[email protected]> Closes #202
* Fix gcc compiler warning, dsl_pool_create()Brian Behlendorf2011-04-191-2/+2
| | | | | | | | | | | | | | When compiling ZFS in user space gcc-4.6.0 correctly identifies the variable 'os' as being set but never used. This generates a warning and a build failure when using --enable-debug. However, the code is correct we only want to use 'os' for the kernel space builds. To suppress the warning the call was wrapped with a VERIFY() which has the nice side effect of ensuring the 'os' actually never is NULL. This was observed under Fedora 15. module/zfs/dsl_pool.c: In function ‘dsl_pool_create’: module/zfs/dsl_pool.c:229:12: error: variable ‘os’ set but not used [-Werror=unused-but-set-variable]
* Linux 2.6.39 compat, invalidate_inodes()Brian Behlendorf2011-04-191-1/+1
| | | | | | | | | Update code to use the spl_invalidate_inodes() wrapper. This hides some of the complexity of determining if invalidate_inodes() was exported, and if so what is its prototype. The second argument of spl_invalidate_inodes() determined the behavior of how dirty inodes are handled. By passing a zero we are indicated that we want those inodes to be treated as busy and skipped.
* Linux 2.6.29 compat, credentialsBrian Behlendorf2011-04-071-3/+3
| | | | | | | The .sync_fs fix as applied did not use the updated SPL credential API. This broke builds on Debian Lenny, this change applies the needed fix to use the portable API. The original credential changes are part of commit 81e97e21872a9c38ad66c37fafe1436ee25abee3.
* Fix ASSERTION(!dsl_pool_sync_context(tx->tx_pool))Brian Behlendorf2011-04-071-0/+13
| | | | | | | | | | Disable the normal reclaim path for the txg_sync thread. This ensures the thread will never enter dmu_tx_assign() which can otherwise occur due to direct reclaim. If this is allowed to happen the system can deadlock. Direct reclaim call path: ->shrink_icache_memory->prune_icache->dispose_list-> clear_inode->zpl_clear_inode->zfs_inactive->dmu_tx_assign
* Add direct+indirect ARC reclaimBrian Behlendorf2011-04-071-0/+59
| | | | | | | | | | | | | | | | | | | | | Under OpenSolaris all memory reclaim is done asyncronously. Under Linux memory reclaim is done asynchronously _and_ synchronously. When a process allocates memory with GFP_KERNEL it explicitly allows the kernel to do reclaim on its behalf to satify the allocation. If that GFP_KERNEL allocation fails the kernel may take more drastic measures to reclaim the memory such as killing user space processes. This was observed to happen with ZFS because the ARC could consume a large fraction of the system memory but no synchronous reclaim could be performed on it. The result was GFP_KERNEL allocations could fail resulting in OOM events, and only moments latter the arc_reclaim thread would free unused memory from the ARC. This change leaves the arc_thread in place to manage the fundamental ARC behavior. But it adds a synchronous (direct) reclaim path for the ARC which can be called when memory is badly needed. It also adds an asynchronous (indirect) reclaim path which is called much more frequently to prune the ARC slab caches.
* Add missing arcstatsBrian Behlendorf2011-04-071-8/+20
| | | | | | | | | | | | The following useful values were missing the arcstats. This change adds them in to provide greater visibility in to the arcs behavior. arc_no_grow 4 0 arc_tempreserve 4 0 arc_loaned_bytes 4 0 arc_meta_used 4 624774592 arc_meta_limit 4 400785408 arc_meta_max 4 625594176
* Call d_instantiate before unlocking inodeBrian Behlendorf2011-04-073-27/+12
| | | | | | | | | Under Linux a dentry referencing an inode must be instantiated before the inode is unlocked. To accomplish this without overly modifing the core ZFS code the dentry it passed via the vattr_t. There are cases such as replay when a dentry is not available. In which case it is obviously not initialized at inode creation time, if a dentry is needed it will be spliced as when required via d_lookup().
* Fix `make distclean` for `./configure --with-config=userBrian Behlendorf2011-04-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Making distclean in module make[1]: Entering directory `/zfs/module' make -C SUBDIRS=`pwd` clean make: Entering an unknown directory make: *** SUBDIRS=/zfs/module: No such file or directory. Stop. When using --with-config=user the 'distclean' target would fail because it assumes the kernel configuration infrastrure is set up. This is not the case, nor does it need to be, because the '--with-config=user' option will prune the entire ./module subtree from SUBDIRS. This prevents most build rules from operating in the ./module directory. However, the 'dist*' rules will still traverse this directory because it is listed in DIST_SUBDIRS. This is correct because we need to ensure the dist rules package the directory contents regardless of the configuration for the 'dist' rule. The correct way to handle this is to only invoke the kernel build system as part of the 'clean' rule when CONFIG_KERNEL_TRUE is set. Initial fix provided by Darik Horn <[email protected]>. This commit is a slightly refined form of the original.
* Fix inflated load averageBrian Behlendorf2011-03-311-2/+2
| | | | | | | | | | | | | | | Kernel threads which sleep uninterruptibly on Linux are marked in the (D) state. These threads are usually in the process of performing IO and are thus counted against the load average. The txg_quiesce and txg_sync threads were always sleeping uninterruptibly and thus inflating the load average. This change makes them sleep interruptibly. Some care is required however because these threads may now be woken early by signals. In this case the callers are all careful to check that the required conditions are met after waking up. If we're woken early due to a signal they will simply go back to sleep. In this case these changes are safe. Closes #175
* Linux 2.6.29 compat, .freeze_fs/.unfreeze_fsBrian Behlendorf2011-03-221-2/+0
| | | | | | The .freeze_fs/.unfreeze_fs hooks were not added until Linux 2.6.29 Since these hooks are currently unused they are being removed to allow support of older kernels.
* Linux 2.6.29 compat, credentialsBrian Behlendorf2011-03-223-81/+81
| | | | | | | As of Linux 2.6.29 a clean credential API was added to the Linux kernel. Previously the credential was embedded in the task_struct. Because the SPL already has considerable support for handling this API change the ZPL code has been updated to use the Solaris credential API.
* Fix evict() deadlockBrian Behlendorf2011-03-221-4/+20
| | | | | | | | | | | | | | | | | | | | | Now that KM_SLEEP is not defined as GFP_NOFS there is the possibility of synchronous reclaim deadlocks. These deadlocks never existed in the original OpenSolaris code because all memory reclaim on Solaris is done asyncronously. Linux does both synchronous (direct) and asynchronous (indirect) reclaim. This commit addresses a deadlock caused by inode eviction. A KM_SLEEP allocation may trigger direct memory reclaim and shrink the inode cache. This can occur while a mutex in the array of ZFS_OBJ_HOLD mutexes is held. Through the ->shrink_icache_memory()->evict()->zfs_inactive()-> zfs_zinactive() call path the same mutex may be reacquired resulting in a deadlock. To avoid this deadlock the process must not reacquire the mutex when it is already holding it. This is a reasonable fix for now but longer term the ZFS_OBJ_HOLD mutex locking should be reevaluated. This infrastructure already prevents us from ever using the Linux lock dependency analysis tools, and it may limit scalability.
* Use KM_PUSHPAGE instead of KM_SLEEPBrian Behlendorf2011-03-223-9/+9
| | | | | | | | | | | | | | | | | | | | | | | It used to be the case that all KM_SLEEP allocations were GFS_NOFS. Unfortunately this often resulted in the kernel being unable to reclaim the ARC, inode, and dentry caches in a timely manor. The fix was to make KM_SLEEP a GFP_KERNEL allocation in the SPL. However, this increases the posibility of deadlocking the system on a zfs write thread. If a zfs write thread attempts to perform an allocation it may trigger synchronous reclaim. This reclaim may attempt to flush dirty data/inode to disk to free memory. Unforunately, this write cannot finish because the write thread which would handle it is holding the previous transaction open. Deadlock. To avoid this all allocations in the zfs write thread path must use KM_PUSHPAGE which prohibits synchronous reclaim for that thread. In this way forward progress in ensured. The risk with this change is I missed updating an allocation for the write threads leaving an increased posibility of deadlock. If any deadlocks remain they will be unlikely but we'll have to make sure they all get fixed.
* Register .remount_fs handlerBrian Behlendorf2011-03-152-1/+51
| | | | | | | | | Register the missing .remount_fs handler. This handler isn't strictly required because the VFS does a pretty good job updating most of the MS_* flags. However, there's no harm in using the hook to call the registered zpl callback for various MS_* flags. Additionaly, this allows us to lay the ground work for more complicated argument parsing in the future.
* Register .sync_fs handlerBrian Behlendorf2011-03-152-8/+26
| | | | | | | | | Register the missing .sync_fs handler. This is a noop in most cases because the usual requirement is that sync just be initiated. As part of the DMU's normal transaction processing txgs will be frequently synced. However, when the 'wait' flag is set the requirement is that .sync_fs must not return until the data is safe on disk. With the addition of the .sync_fs handler this is now properly implemented.
* Don't set I/O Scheduler for PartitionsBrian Behlendorf2011-03-101-0/+4
| | | | | | | | | ZFS should only change the i/o scheduler for a disk when it has ownership of the whole disk. This is basically the same logic as adjusting the write cache behavior on a disk. This change updates the vdev disk code to skip partitions when setting the i/o scheduler. Closes #152
* Fix O_APPEND CorruptionBrian Behlendorf2011-03-091-0/+1
| | | | | | | | | | | | | | | | | | | Due to an uninitialized variable files opened with O_APPEND may overwrite the start of the file rather than append to it. This was introduced accidentally when I removed the Solaris vnodes. The zfs_range_lock_writer() function used to key off zf->z_vnode to determine if a znode_t was for a zvol of zpl object. With the removal of vnodes this was replaced by the flag zp->z_is_zvol. This flag was used to control the append behavior for range locks. Unfortunately, this value was never properly initialized after the vnode removal. However, because most of memory is usually zeros it happened to be set correctly most of the time making the bug appear racy. Properly initializing zp->z_is_zvol to zero completely resolves the problem with O_APPEND. Closes #126
* Conserve stack in zfs_setattr()Brian Behlendorf2011-03-091-1/+6
| | | | | | | | Move 'bulk' and 'xattr_bulk' from the stack to the heap to minimize stack space usage. These two arrays consumed 448 bytes on the stack and have been replaced by two 8 byte points for a total stack space saving of 432 bytes. The zfs_setattr() path had been previously observed to overrun the stack in certain circumstances.
* Range lock performance improvementsBrian Behlendorf2011-03-081-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original range lock implementation had to be modified by commit 8926ab7 because it was unsafe on Linux. In particular, calling cv_destroy() immediately after cv_broadcast() is dangerous because the waiters may still be asleep. Thus the following cv_destroy() will free memory which may still be in use. This was fixed by updating cv_destroy() to block on waiters but this in turn introduced a deadlock. The deadlock was resolved with the use of a taskq to move the offending free outside the range lock. This worked well but using the taskq for the free resulted in a serious performace hit. This is somewhat ironic because at the time I felt using the taskq might improve things by making the free asynchronous. This patch refines the original fix and moves the free from the taskq to a private free list. Then items which must be free'd are simply inserted in to the list. When the range lock is dropped it's safe to free the items. The list is walked and all rl_t entries are freed. This change improves small cached read performance by 26x. This was expected because for small reads the number of locking calls goes up significantly. More surprisingly this change significantly improves large cache read performance. This probably attributable to better cpu/memory locality. Very likely the same processor which allocated the memory is now freeing it. bs ext3 zfs zfs+fix faster ---------------------------------------------- 512 435 3 79 26x 1k 820 7 160 22x 2k 1536 14 305 21x 4k 2764 28 572 20x 8k 3788 50 1024 20x 16k 4300 86 1843 21x 32k 4505 138 2560 18x 64k 5324 252 3891 15x 128k 5427 276 4710 17x 256k 5427 413 5017 12x 512k 5427 497 5324 10x 1m 5427 521 5632 10x Closes #142
* Add zfs_open()/zfs_close()Brian Behlendorf2011-03-082-1/+103
| | | | | | | | | | | | | | | | | | | In the original implementation the zfs_open()/zfs_close() hooks were dropped for simplicity. This was functional but not 100% correct with the expected ZFS sematics. Updating and re-adding the zfs_open()/zfs_close() hooks resolves the following issues. 1) The ZFS_APPENDONLY file attribute is once again honored. While there are still no Linux tools to set/clear these attributes once there are it should behave correctly. 2) Minimal virus scan file attribute hooks were added. Once again this support in disabled but the infrastructure is back in place. 3) Most importantly correctly handle assigning files which were opened syncronously to the intent log. Without this change O_SYNC modifications could be lost during a system crash even though they were marked synchronous.
* Set stat->st_dev and statfs->f_fsidBrian Behlendorf2011-03-073-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Filesystems like ZFS must use what the kernel calls an anonymous super block. Basically, this is just a filesystem which is not backed by a single block device. Normally this block device's dev_t is stored in the super block. For anonymous super blocks a unique reserved dev_t is assigned as part of get_sb(). This sb->s_dev must then be set in the returned stat structures as stat->st_dev. This allows userspace utilities to easily detect the boundries of a specific filesystem. Tools such as 'du' depend on this for proper accounting. Additionally, under OpenSolaris the statfs->f_fsid is set to the device id. To preserve consistency with OpenSolaris we also set the fsid to the device id. Other Linux filesystem (ext) set the fsid to a unique value determined by the filesystems uuid. This value is unique but maintains no relationship to the device id. This may be desirable when exporting NFS filesystem because it minimizes to chance of a client observing the same fsid from two different servers. Closes #140
* Use Linux ATTR_ versionsBrian Behlendorf2011-03-031-2/+2
| | | | | | The AT_ versions of these macros are used on Solaris and while they map to their Linux equivilants the code has been updated to use the ATTR_ versions.
* Conserve stack in zfs_setattr()Brian Behlendorf2011-03-021-44/+39
| | | | | | | | Move 'tmpxvattr' from the stack to the heap to minimize stack space usage. This is enough to get us below the 1024 byte stack frame warning. That however is still a large stack frame and it should be further reduced by moving the 'bulk' and 'xattr_bulk' sa_bulk_attr_t variables to the heap in a future patch.
* Drop HAVE_XVATTR macrosBrian Behlendorf2011-03-027-177/+528
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When I began work on the Posix layer it immediately became clear to me that to integrate cleanly with the Linux VFS certain Solaris specific things would have to go. One of these things was to elimate as many Solaris specific types from the ZPL layer as possible. They would be replaced with their Linux equivalents. This would not only be good for performance, but for the general readability and health of the code. The Solaris and Linux VFS are different beasts and should be treated as such. Most of the code remains common for constructing transactions and such, but there are subtle and important differenced which need to be repsected. This policy went quite for for certain types such as the vnode_t, and it initially seemed to be working out well for the vattr_t. There was a relatively small amount of related xvattr_t code I was forced to comment out with HAVE_XVATTR. But it didn't look that hard to come back soon and replace it all with a native Linux type. However, after going doing this path with xvattr some distance it clear that this code was woven in the ZPL more deeply than I thought. In particular its hooks went very deep in to the ZPL replay code and replacing it would not be as easy as I originally thought. Rather than continue persuing replacing and removing this code I've taken a step back and reevaluted things. This commit reverts many of my previous commits which removed xvattr related code. It restores much of the code to its original upstream state and now relies on improved xvattr_t support in the zfs package itself. The result of this is that much of the code which I had commented out, which accidentally broke things like replay, is now back in place and working. However, there may be a small performance impact for getattr/setattr operations because they now require a translation from native Linux to Solaris types. For now that's a price I'm willing to pay. Once everything is completely functional we can revisting the issue of removing the vattr_t/xvattr_t types. Closes #111
* Remove caller_context_tBrian Behlendorf2011-03-021-12/+7
| | | | | Remove the remaining callers of caller_context_t. This type has been removed because it is not needed for the Linux port.
* Add the zpool and filesystem versionsDarik Horn2011-02-281-3/+5
| | | | | | | | | | | | | Print the supported zpool and filesystem versions at module load time. This change removes an ambiguity and adds information that system administrators care about. The phrase "ZFS pool version %s" is the same as zpool upgrade -v so that the operator is familiar with the message. ZFS: Loaded module v0.6.0, ZFS pool version 28, ZFS filesystem version 5 ZFS: Unloaded module v0.6.0 Signed-off-by: Brian Behlendorf <[email protected]>
* Fix set block scheduler warningsBrian Behlendorf2011-02-251-6/+23
| | | | | | | | | | | | | | | | | | | | There were two cases when attempting to set the vdev block device scheduler which would causes console warnings. The first case was when the vdev used a loop, ram, dm, or other such device which doesn't support a configurable scheduler. In these cases attempting to set a scheduler is pointless and can be safely skipped. The secord case is slightly more troubling. We were seeing transient cases where setting the elevator would return -EFAULT. On retry everything is fine so there appears to be a small window where this is possible. To handle that case we silently retry up to three times before reporting the warning. In all of the above cases the warning is harmless and at worse you may see slightly different performance characteristics from one or more of your vdevs.
* Use udev to create /dev/zvol/[dataset_name] linksFajar A. Nugraha2011-02-251-6/+10
| | | | | | | | | | | | | | | | | This commit allows zvols with names longer than 32 characters, which fixes issue on https://github.com/behlendorf/zfs/issues/#issue/102. Changes include: - use /dev/zd* device names for zvol, where * is the device minor (include/sys/fs/zfs.h, module/zfs/zvol.c). - add BLKZNAME ioctl to get dataset name from userland (include/sys/fs/zfs.h, module/zfs/zvol.c, cmd/zvol_id). - add udev rule to create /dev/zvol/[dataset_name] and the legacy /dev/[dataset_name] symlink. For partitions on zvol, it will create /dev/zvol/[dataset_name]-part* (etc/udev/rules.d/60-zvol.rules, cmd/zvol_id). Signed-off-by: Brian Behlendorf <[email protected]>
* Remove rdev packingBrian Behlendorf2011-02-231-35/+1
| | | | | | | | | | | | | | | | | Remove custom code to pack/unpack dev_t's. Under Linux all dev_t's are an unsigned 32-bit value even on 64-bit platforms. The lower 20 bits are used for the minor number and the upper 12 for the major number. This means if your importing a pool from Solaris you may get strange major/minor numbers. But it doesn't really matter because even if we add compatibility code to translate the encoded Solaris major/minor they won't do you any good under Linux. You will still need to recreate the dev_t with a major/minor which maps to reserved major numbers used under Linux. Dropping this code also resolves 32-bit builds by removing the offending 32-bit compatibility code.
* Use correct ASSERT3* variantBrian Behlendorf2011-02-231-1/+1
| | | | | | ASSERT3P should be used instead of ASSERT3U when comparing pointers. Using ASSERT3U with the cast causes a compiler warning for 32-bit builds which is fatal with --enable-debug.
* Increase fragment size to block sizeBrian Behlendorf2011-02-231-4/+8
| | | | | | | | | | | | The underlying storage pool actually uses multiple block size. Under Solaris frsize (fragment size) is reported as the smallest block size we support, and bsize (block size) as the filesystem's maximum block size. Unfortunately, under Linux the fragment size and block size are often used interchangeably. Thus we are forced to report both of them as the filesystem's maximum block size. Closes #112
* Fix 'statement with no effect' warningBrian Behlendorf2011-02-231-1/+1
| | | | | | | | Because the secpolicy_* macros are all currently defined to (0). And because the caller of this function does not check the return code. The compiler complains that this statement has no effect which is correct and OK. To suppress the warning explictly cast the result to (void).
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 21:08:14 +0000