aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Export additional dsl symbolsBrian Behlendorf2012-04-112-1/+12
| | | | | | | | | Principly these symbols were exported to get access to the dsl_prop_register/dsl_prop_unregister functions. They allow us to cleanly register a callback which is called when a dataset property is modified. Signed-off-by: Brian Behlendorf <[email protected]>
* Fixed a NULL pointer dereference bug in zfs_preumountGunnar Beutner2012-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When zpl_fill_super -> zfs_domount fails (e.g. because the dataset was destroyed before it could be successfully mounted) the subsequent call to zpl_kill_sb -> zfs_preumount would derefence a NULL pointer. This bug can be reproduced using this shell script: #!/bin/sh ( while true; do zfs create -o mountpoint=legacz tank/bar zfs destroy tank/bar done ) & ( while true; do mount -t zfs tank/bar /mnt umount /mnt done ) & Signed-off-by: Brian Behlendorf <[email protected]> Closes #639
* Make Gentoo initscript use modinfoRichard Yao2012-04-031-1/+1
| | | | | | | | | The -l parameter to modprobe has been removed from the latest upstream code and this change has entered Gentoo. Using modinfo as a substitute addresses this. Signed-off-by: Brian Behlendorf <[email protected]> Closes #636
* Print human readable error message for ENOENTRichard Yao2012-04-031-0/+4
| | | | | | | | | | | | | | | A cryptic error code is printed when mounting a legacy dataset to a non-existent mountpoint. This patch changes this behavior to print "mount point '%s' does not exist", which is similar to the error message printed when mounting procfs. The single quotes were added to be consistent with the existing EBUSY error message, which is the only difference between this error message and the one that is printed when the same condition occurs when mounting procfs. Signed-off-by: Brian Behlendorf <[email protected]> Closes #633
* Properly expose the mfu ghost list kstatsBrian Behlendorf2012-03-271-1/+1
| | | | | | | | Due to a typo the mru ghost lists stats were accidentally being exposed as the mfu ghost list stats. This was harmless but confusing since memory usage could be over reported. Signed-off-by: Brian Behlendorf <[email protected]>
* Remove hard-coded 80 column outputCraig Sanders2012-03-271-4/+25
| | | | | | | | When stdout is detected to be a tty use the number of columns specified by the terminal. If that fails fall back to a default 80 column width. In the non-tty case allow for 999 column lines. Signed-off-by: Brian Behlendorf <[email protected]>
* ZFS 0.6.0-rc8zfs-0.6.0-rc8Brian Behlendorf2012-03-261-1/+1
|
* Fix executable permissionsBrian Behlendorf2012-03-263-0/+1
| | | | | | | | | | | | Caught by lint, this permission change was accidentally introduced by commit 42cb3819f1a1f536105faac81ffc150f3da90a80. Restore the correct permissions and while I'm at it add a missing whack-bang to config/ltmain.sh. lint: executable-not-elf-or-script: zpool_main.c zfs_main.c Signed-off-by: Brian Behlendorf <[email protected]> Closes #620
* Add --enable-debug-dmu-tx configure optionBrian Behlendorf2012-03-2362-25/+154
| | | | | | | | | | | | | | | | | | Allow rigorous (and expensive) tx validation to be enabled/disabled indepentantly from the standard zfs debugging. When enabled these checks ensure that all txs are constructed properly and that a dbuf is never dirtied without taking the correct tx hold. This checking is particularly helpful when adding new dmu consumers like Lustre. However, for established consumers such as the zpl with no known outstanding tx construction problems this is just overhead. --enable-debug-dmu-tx - Enable/disable validation of each tx as --disable-debug-dmu-tx it is constructed. By default validation is disabled due to performance concerns. Signed-off-by: Brian Behlendorf <[email protected]>
* Enhance a dmu_tx_dirty_buf() assertionBrian Behlendorf2012-03-231-1/+2
| | | | | | | | | | | | The following assertion is good to validate the correctness of new DMU consumers, but it doesn't quite provide enough information. Slightly rework the assertion so that when it is hit the actual offending values will be included in the output. SPLError: 4787:0:(dmu_tx.c:828:dmu_tx_dirty_buf()) ASSERTION(dn == NULL || dn->dn_assigned_txg == tx->tx_txg) failed Signed-off-by: Brian Behlendorf <[email protected]>
* Add ZFS_META_RELEASE to module load/unload messagesBrian Behlendorf2012-03-231-6/+7
| | | | | | | | Include the ZFS_META_RELEASE in the module load/unload messages to more clearly indidcate exactly what version of ZFS has been loaded. Signed-off-by: Brian Behlendorf <[email protected]>
* Account for .zfs ctldir inodesBrian Behlendorf2012-03-221-0/+1
| | | | | | | | | | | | | | Because the .zfs ctldir inodes are not backed by physical storage they use a different create path which was not properly accounting for them as used. This could result in ->nr_cached_objects() returning 0 and cause a divide by zero error in prune_super(). In my option there's a kernel bug here too which allows this to happen. They should either be checking for 0 or adding +1 like they correctly do earlier in the function. Signed-off-by: Brian Behlendorf <[email protected]> Closes #617
* Add .zfs control directoryBrian Behlendorf2012-03-2279-101/+2037
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the .zfs control directory. This was accomplished by leveraging as much of the existing ZFS infrastructure as posible and updating it for Linux as required. The bulk of the core functionality is now all there with the following limitations. *) The .zfs/snapshot directory automount support requires a 2.6.37 or newer kernel. The exception is RHEL6.2 which has backported the d_automount patches. *) Creating/destroying/renaming snapshots with mkdir/rmdir/mv in the .zfs/snapshot directory works as expected. However, this functionality is only available to root until zfs delegations are finished. * mkdir - create a snapshot * rmdir - destroy a snapshot * mv - rename a snapshot The following issues are known defeciences, but we expect them to be addressed by future commits. *) Add automount support for kernels older the 2.6.37. This should be possible using follow_link() which is what Linux did before. *) Accessing the .zfs/snapshot directory via NFS is not yet possible. The majority of the ground work for this is complete. However, finishing this work will require resolving some lingering integration issues with the Linux NFS kernel server. *) The .zfs/shares directory exists but no futher smb functionality has yet been implemented. Contributions-by: Rohan Puri <[email protected]> Contributiobs-by: Andrew Barnes <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #173
* Add zio constructor/destructorBrian Behlendorf2012-03-211-15/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a standard zio constructor and destructor. Normally, this is done to reduce to cost of allocating a new structure by reducing expensive operations such as memory allocations. However, in this case none of the operations moved out of zio_create() were really very expensive. This change was principly made as a debug patch (and workaround) for a zio_destroy() race. The is good evidence that zio_create() is reinitializing a mutex which is really still in use by another thread. This would completely explain the observed symptoms in the issue report. This patch doesn't fix the root cause of the race, but it should make it less likely by only initializing the mutex once in the constructor. Also, this particular flaw might have gone unnoticed in other zfs implementations due to the specific implementation details of Linux ticket spinlocks. Once the real root cause is determined and resolved this change can be safely reverted. Until then this should help workaround the issue. Signed-off-by: Brian Behlendorf <[email protected]> Issue #496
* Revert "Add zio constructor/destructor"Brian Behlendorf2012-03-211-62/+15
| | | | | | | | | | | | | | | | | | | This patch was slightly flawed and allowed for zio->io_logical to potentially not be reinitialized for a new zio. This could lead to assertion failures in specific cases when debugging is enabled (--enable-debug) and I/O errors are encountered. It may also have caused problems when issues logical I/Os. Since we want to make sure this workaround can be easily removed in the future (when we have the real fix). I'm reverting this change and applying a new version of the patch which includes the zio->io_logical fix. This reverts commit 2c6d0b1e07b0265f0661ed7851d3aa8d3e75e7a9. Signed-off-by: Brian Behlendorf <[email protected]> Issue #602 Issue #604
* ZFS 0.6.0-rc7zfs-0.6.0-rc7Brian Behlendorf2012-03-161-1/+1
|
* Add missing NULL in zpl_xattr_handlersBrian Behlendorf2012-03-151-0/+1
| | | | | | | | | | | | | The xattr_resolve_name() helper function expects the registered list of xattr handlers to be NULL terminated. This NULL was accidentally missing which could result in a NULL dereference. Interestingly this issue only manifested itself on certain 32-bit systems. Presumably on 64-bit kernels we just always happen to get lucky and the memory following the structure is zeroed. Signed-off-by: Brian Behlendorf <[email protected]> Issue #594
* Use stderr for 'no pools/datasets available' errorGregor Kopka2012-03-152-6/+6
| | | | | | | | | | | The 'zfs list' and 'zpool list' commands output the message 'no datasets/pools available' to stdout. This should go to stderr and only the available datasets/pools should go to stdout. Returning nothing to stdout is expected behavior when there is nothing to list. Signed-off-by: Brian Behlendorf <[email protected]> Closes #581
* Add sa_spill_rele() interfaceBrian Behlendorf2012-03-072-0/+15
| | | | | | | | | | | Add a SA interface which allows us to release the spill block from a SA handle without destroying the handle. This is useful because we can then ensure that a copy of the dirty spill block is not made at sync time due to the extra hold. Susequent calls to sa_update() or sa_lookup() with transparently refetch the spill block dbuf from the ARC hash. Signed-off-by: Brian Behlendorf <[email protected]>
* Add zio constructor/destructorBrian Behlendorf2012-03-071-15/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a standard zio constructor and destructor. Normally, this is done to reduce to cost of allocating a new structure by reducing expensive operations such as memory allocations. However, in this case none of the operations moved out of zio_create() were really very expensive. This change was principly made as a debug patch (and workaround) for a zio_destroy() race. The is good evidence that zio_create() is reinitializing a mutex which is really still in use by another thread. This would completely explain the observed symptoms in the issue report. This patch doesn't fix the root cause of the race, but it should make it less likely by only initializing the mutex once in the constructor. Also, this particular flaw might have gone unnoticed in other zfs implementations due to the specific implementation details of Linux ticket spinlocks. Once the real root cause is determined and resolved this change can be safely reverted. Until then this should help workaround the issue. Signed-off-by: Brian Behlendorf <[email protected]> Issue #496
* Fix distribution detectionRichard Yao2012-03-052-50/+58
| | | | | | | | | | | | | | Improve the distribution detection by moving the tests for distribution specific files first. The Ubuntu and Debian checks are left for last because they are the least likely to be unique. This is particularly true in the case of Debian since so many distributions are based on Debian. Since this is currently only used to identify the correct packaging method for this system the result in many instances is simply cosmetic. Signed-off-by: Brian Behlendorf <[email protected]>
* Align parition end on 1 MiB boundaryNed Bass2012-03-051-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | Some devices have exhibited sensitivity to the ending alignment of partitions. In particular, even if the first partition begins at 1 MiB, we have seen many sd driver task abort errors with certain SSDs if the first partition doesn't end on a 1 MiB boundary. This occurs when the vdev label is read during pool creation or importation and causes a delay of about 30 seconds per device. It can also be simulated with dd when the pool isn't imported: dd if=/dev/sda1 of=/dev/null bs=262144 count=1 For the record, this problem was observed with SMARTMOD SG9XCA2E200GE01 200GB SSDs. Unfortunately I don't have a good explanation for this behavior. It seems to have something to do with highly fragmented single-sector requests being issued to the device, which it may not support. With end-aligned partitions at least page-sized requests were queued and issued to the driver according to blktrace. In any case, aligning the partition end is a fairly innocuous work-around, wasting at most 1 MiB of space. Signed-off-by: Brian Behlendorf <[email protected]> Closes #574
* Use SA_HDL_PRIVATE for SA xattrsBrian Behlendorf2012-03-021-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A private SA handle must be used to ensure we can drop the dbuf hold on the spill block prior to calling dmu_tx_commit(). If we call dmu_tx_commit() before sa_handle_destroy(), then our hold will trigger a copy of the dbuf to be made. This is done to prevent data from leaking in to the syncing txg. As a result the original dirty spill block will remain cached. Additionally, relying on the shared zp->z_sa_hdl is unsafe in the xattr context because the znode may be asynchronously dropped from the cache. It's far safer and simpler just to use a private handle for xattrs. Plus any additional overhead is offset by the avoidance of the previously mentioned memory copy. These forever dirty buffers can be noticed in the arcstats under the anon_size. On a quiescent system the value should be zero. Without this fix and a SA xattr write workload you will see anon_size increase. Eventually, if enough dirty data builds up your system it will appear to hang. This occurs because the dmu won't allow new txs to be assigned until that dirty data is flushed, and it won't be because it's not part of an assigned tx. As an aside, I typically see anon_size lurk around 16k so I think there is another place in the code which needs a similar fix. However, this value doesn't grow over time so it isn't critical. Signed-off-by: Brian Behlendorf <[email protected]> Issue #503 Issue #513
* Cleanly support debug packagesBrian Behlendorf2012-02-2760-16/+99
| | | | | | | | | | | | | | | | | | | Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs # For example: $ rpmbuild --rebuild --with debug zfs-modules-0.6.0-rc6.src.rpm Additionally, ZFS_CONFIG has been added to zfs_config.h for packages which build against these headers. This is critical to ensure both zfs and the dependant package are using the same prototype and structure definitions. Signed-off-by: Brian Behlendorf <[email protected]>
* Add 'dmu_tx' kstats entryBrian Behlendorf2012-02-277-4/+93
| | | | | | | | | Keep counters for the various reasons that a thread may end up in txg_wait_open() waiting on a new txg. This can be useful when attempting to determine why a particular workload is under performing. Signed-off-by: Brian Behlendorf <[email protected]>
* Add arc_state_t stats to arcstatsBrian Behlendorf2012-02-271-0/+73
| | | | | | | | | | To ensure the arc is behaving properly we need greater visibility in to exactly how it's managing the systems memory. This patch takes one step in that direction be adding the current arc_state_t for the anon, mru, mru_ghost, mfu, and mfs_ghost lists. The l2 arc_state_t is already well represented in the arcstats. Signed-off-by: Brian Behlendorf <[email protected]>
* Return success from check_slice() if device doesn't existNed Bass2012-02-271-9/+0
| | | | | | | | | | | | | | | When creating a new pool, make_root_vdev() calls check_in_use() to ensure that none of the consituent disks are in use. If the disk contains a valid vdev label it is read to retrieve the list of its child vdevs and these are checked recursively. However, the partitions stored in the vdev label my no longer exist, for example if the partition table has since been altered. In any such case we would want the pool creation to proceed, so this change removes the check from check_slice() that returns an error if the device doesn't exist. As an added assurance, the Solaris implementation also returns sucess on ENOENT. Signed-off-by: Brian Behlendorf <[email protected]>
* Export symbols for zero-copyAlex Zhuravlev2012-02-171-0/+2
| | | | | | | | Export additional symbols to make use of the DMU's zero-copy API. This allows external modules to move data in to and out of the ARC without incurring the cost of a memory copy. Signed-off-by: Brian Behlendorf <[email protected]>
* Support ashift=13 for 8KB SSD block sizesRichard Yao2012-02-132-2/+2
| | | | | | | | | | | | | | New SSDs are now available which use an internal 8k block size. To make sure ZFS can get the maximum performance out of these devices we're increasing the maximum ashift to 13 (8KB). This value is still small enough that we can fit 16 uberblocks in the vdev ring label. However, I don't want to increase this any futher or it will limit the ability the safely roll back a pool to recover it. Signed-off-by: Brian Behlendorf <[email protected]> Closes #565
* Add 'fsid' mount option to allowed options.Turbo Fredriksson2012-02-131-1/+1
| | | | | | | | | | Resolves nfs-utils-1.0.x compatibility issue which requires that the fsid be set in the export options. exportfs: Warning: /tank/dir requires fsid= for NFS export Signed-off-by: Brian Behlendorf <[email protected]> Closes #570
* Export symbols for zero-copyBrian Behlendorf2012-02-101-4/+4
| | | | | | | | Exported the required symbols to make use of the DMU's zero-copy API. This allows external modules to move data in to and out of the ARC without incurring the cost of a memory copy. Signed-off-by: Brian Behlendorf <[email protected]>
* Use spl_debug_* helpersBrian Behlendorf2012-02-091-2/+2
| | | | | | | | When configuring the spl debug log support use the provided wrapper functions. This ensures that if --disable-debug-log was used when buiding the spl the functions will have no effect. Signed-off-by: Brian Behlendorf <[email protected]>
* Add support for DISCARD to ZVOLs.Etienne Dechamps2012-02-0960-0/+273
| | | | | | | | | | | | | | | | | | | | DISCARD (REQ_DISCARD, BLKDISCARD) is useful for thin provisioning. It allows ZVOL clients to discard (unmap, trim) block ranges from a ZVOL, thus optimizing disk space usage by allowing a ZVOL to shrink instead of just grow. We can't use zfs_space() or zfs_freesp() here, since these functions only work on regular files, not volumes. Fortunately we can use the low-level function dmu_free_long_range() which does exactly what we want. Currently the discard operation is not added to the log. That's not a big deal since losing discard requests cannot result in data corruption. It would however result in disk space usage higher than it should be. Thus adding log support to zvol_discard() is probably a good idea for a future improvement. Signed-off-by: Brian Behlendorf <[email protected]>
* Support the fallocate() file operation.Etienne Dechamps2012-02-0961-0/+447
| | | | | | | | | | | | | | Currently only the (FALLOC_FL_PUNCH_HOLE) flag combination is supported, since it's the only one that matches the behavior of zfs_space(). This makes it pretty much useless in its current form, but it's a start. To support other flag combinations we would need to modify zfs_space() to make it more flexible, or emulate the desired functionality in zpl_fallocate(). Signed-off-by: Brian Behlendorf <[email protected]> Issue #334
* Check permissions in zfs_space().Etienne Dechamps2012-02-091-0/+11
| | | | | | | | | | This isn't done on Solaris because on this OS zfs_space() can only be called with an opened file handle. Since the addition of zpl_truncate_range() this isn't the case anymore, so we need to enforce access rights. Signed-off-by: Brian Behlendorf <[email protected]> Issue #334
* Implement the truncate_range() inode operation.Etienne Dechamps2012-02-091-0/+28
| | | | | | | | | | | | | | | | This operation allows "hole punching" in ZFS files. On Solaris this is done via the vop_space() system call, which maps to the zfs_space() function. So we just need to write zpl_truncate_range() as a wrapper around zfs_space(). Note that this only works for regular files, not ZVOLs. This is currently an insecure implementation without permission checking, although this isn't that big of a deal since truncate_range() isn't even callable from userspace. Signed-off-by: Brian Behlendorf <[email protected]> Issue #334
* Fix zconfig.sh non-optimal alignmentBrian Behlendorf2012-02-092-56/+67
| | | | | | | | | | | | | | | The recent zvol improvements have changed default suggested alignment for zvols from 512b (default) to 8k (zvol blocksize). Because of this the zconfig.sh tests which create paritions are now generating a warning about non-optimal alignments. This change updates the need zconfig.sh tests such that a partition will be properly aligned. In the process, it shifts from using the sfdisk utility to the parted utility to create partitions. It also moves the creation of labels, partitions, and filesystems in to generic functions in common.sh.in. Signed-off-by: Brian Behlendorf <[email protected]>
* Use 32 as the default number of zvol threads.Etienne Dechamps2012-02-081-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the `zvol_threads` variable, which controls the number of worker threads which process items from the ZVOL queues, is set to the number of available CPUs. This choice seems to be based on the assumption that ZVOL threads are CPU-bound. This is not necessarily true, especially for synchronous writes. Consider the situation described in the comments for `zil_commit()`, which is called inside `zvol_write()` for synchronous writes: > itxs are committed in batches. In a heavily stressed zil there will be a > commit writer thread who is writing out a bunch of itxs to the log for a > set of committing threads (cthreads) in the same batch as the writer. > Those cthreads are all waiting on the same cv for that batch. > > There will also be a different and growing batch of threads that are > waiting to commit (qthreads). When the committing batch completes a > transition occurs such that the cthreads exit and the qthreads become > cthreads. One of the new cthreads becomes he writer thread for the batch. > Any new threads arriving become new qthreads. We can easily deduce that, in the case of ZVOLs, there can be a maximum of `zvol_threads` cthreads and qthreads. The default value for `zvol_threads` is typically between 1 and 8, which is way too low in this case. This means there will be a lot of small commits to the ZIL, which is very inefficient compared to a few big commits, especially since we have to wait for the data to be on stable storage. Increasing the number of threads will increase the amount of data waiting to be commited and thus the size of the individual commits. On my system, in the context of VM disk image storage (lots of small synchronous writes), increasing `zvol_threads` from 8 to 32 results in a 50% increase in sequential synchronous write performance. We should choose a more sensible default for `zvol_threads`. Unfortunately the optimal value is difficult to determine automatically, since it depends on the synchronous write latency of the underlying storage devices. In any case, a hardcoded value of 32 would probably be better than the current situation. Having a lot of ZVOL threads doesn't seem to have any real downside anyway. Signed-off-by: Brian Behlendorf <[email protected]> Fixes #392
* Improve ZVOL queue behavior.Etienne Dechamps2012-02-0764-0/+1159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linux block device queue subsystem exposes a number of configurable settings described in Linux block/blk-settings.c. The defaults for these settings are tuned for hard drives, and are not optimized for ZVOLs. Proper configuration of these options would allow upper layers (I/O scheduler) to take better decisions about write merging and ordering. Detailed rationale: - max_hw_sectors is set to unlimited (UINT_MAX). zvol_write() is able to handle writes of any size, so there's no reason to impose a limit. Let the upper layer decide. - max_segments and max_segment_size are set to unlimited. zvol_write() will copy the requests' contents into a dbuf anyway, so the number and size of the segments are irrelevant. Let the upper layer decide. - physical_block_size and io_opt are set to the ZVOL's block size. This has the potential to somewhat alleviate issue #361 for ZVOLs, by warning the upper layers that writes smaller than the volume's block size will be slow. - The NONROT flag is set to indicate this isn't a rotational device. Although the backing zpool might be composed of rotational devices, the resulting ZVOL often doesn't exhibit the same behavior due to the COW mechanisms used by ZFS. Setting this flag will prevent upper layers from making useless decisions (such as reordering writes) based on incorrect assumptions about the behavior of the ZVOL. Signed-off-by: Brian Behlendorf <[email protected]>
* Fix synchronicity for ZVOLs.Etienne Dechamps2012-02-0760-3/+433
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zvol_write() assumes that the write request must be written to stable storage if rq_is_sync() is true. Unfortunately, this assumption is incorrect. Indeed, "sync" does *not* mean what we think it means in the context of the Linux block layer. This is well explained in linux/fs.h: WRITE: A normal async write. Device will be plugged. WRITE_SYNC: Synchronous write. Identical to WRITE, but passes down the hint that someone will be waiting on this IO shortly. WRITE_FLUSH: Like WRITE_SYNC but with preceding cache flush. WRITE_FUA: Like WRITE_SYNC but data is guaranteed to be on non-volatile media on completion. In other words, SYNC does not *mean* that the write must be on stable storage on completion. It just means that someone is waiting on us to complete the write request. Thus triggering a ZIL commit for each SYNC write request on a ZVOL is unnecessary and harmful for performance. To make matters worse, ZVOL users have no way to express that they actually want data to be written to stable storage, which means the ZIL is broken for ZVOLs. The request for stable storage is expressed by the FUA flag, so we must commit the ZIL after the write if the FUA flag is set. In addition, we must commit the ZIL before the write if the FLUSH flag is set. Also, we must inform the block layer that we actually support FLUSH and FUA. Signed-off-by: Brian Behlendorf <[email protected]>
* Support "sync=always" for ZVOLs.Etienne Dechamps2012-02-071-1/+1
| | | | | | | | Currently the "sync=always" property works for regular ZFS datasets, but not for ZVOLs. This patch remedies that. Signed-off-by: Brian Behlendorf <[email protected]> Fixes #374.
* Let libnvpair be linked independently of libzfs.Darik Horn2012-02-074-3/+9
| | | | | | | | | | | | Autoconf will fail to detect the ZoL libnvpair on systems that do not implicitly link library runtime dependencies, which is anything that has the GCC 4.5 DCO update. Build libuutil before libnvpair, and put it on the the LDADD line of the libnvpair automake template. Signed-off-by: Brian Behlendorf <[email protected]> Closes: #560
* Linux 3.3 compat, sops->show_options()Brian Behlendorf2012-02-0359-7/+234
| | | | | | | | | | The second argument of sops->show_options() was changed from a 'struct vfsmount *' to a 'struct dentry *'. Add an autoconf check to detect the API change and then conditionally define the expected interface. In either case we are only interested in the zfs_sb_t. Signed-off-by: Brian Behlendorf <[email protected]> Closes #549
* Cleanup ZFS debug infrastructureBrian Behlendorf2012-02-027-162/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | Historically the internal zfs debug infrastructure has been scattered throughout the code. Since we expect to start making more use of this code this patch performs some cleanup. * Consolidate the zfs debug infrastructure in the zfs_debug.[ch] files. This includes moving the zfs_flags and zfs_recover variables, plus moving the zfs_panic_recover() function. * Remove the existing unused functionality in zfs_debug.c and replace it with code which correctly utilized the spl logging infrastructure. * Remove the __dprintf() function from zfs_ioctl.c. This is dead code, the dprintf() functionality in the kernel relies on the spl log support. * Remove dprintf() from hdr_recl(). This wasn't particularly useful and was missing the required format specifier anyway. * Subsequent patches should unify the dprintf() and zfs_dbgmsg() functions. Signed-off-by: Brian Behlendorf <[email protected]>
* Allow multiple values per directory entryBrian Behlendorf2012-02-022-6/+28
| | | | | | | | | | | | | | | | | | | | When using zfs to back a Lustre filesystem it's advantageous to to store a fid with the object id in the directory zap. The only technical impediment to doing this is that the zpl code expects a single value in the zap per directory entry. This change relaxes that requirement such that multiple entries are allowed provided the first one is the object id. The zpl code will just ignore additional entries. This allows the ZoL count to mount datasets which are being used as Lustre server backends. Once the upstream feature flags support is merged in this change should be updated to a read-only feature. Until this occurs other zfs implementations will not be able to read the zfs filesystems created by Lustre. Signed-off-by: Brian Behlendorf <[email protected]>
* Export symbol zfs_attr_tableBrian Behlendorf2012-01-271-0/+1
| | | | | | | | Export the zfs_attr_table symbol so it may be used by non-zpl consumers which are still interested in writing a zpl compatible dataset (e.g. Lustre). Signed-off-by: Brian Behlendorf <[email protected]>
* Ignore dataset if the dds_type is DMU_OST_OTHERPrakash Surya2012-01-191-0/+3
| | | | | | | | | | | | Since the zpios and potentially other ZFS tests use the DMU_OST_OTHER type to label their datasets, the zpool and zfs commands should gracefully handle this type when it is encountered. This patch modifies the commands' behavior to ignore any datasets with a dds_type of DMU_OST_OTHER. Signed-off-by: Prakash Surya <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #536
* Fix rpm dependenciesBrian Behlendorf2012-01-182-10/+11
| | | | | | | | | | | | | | | | | | | | | | | This change updates the rpm spec files to have strictly correct package dependencies. That means a few things: * The zfs-modules package is now tied to a specific build of the spl-modules packages based on the kernel version. This ensures that the correct spl-modules packages will always get installed and not just the newest. * The zfs package now requires both the zfs-modules and spl packages. Thus a 'yum install zfs' will pull in the minimal set of packages required for a functional system. * The zfs-devel packages now require the zfs package to be installed which is normal behavior for -devel packages. * Remove the redundant distribution release extension. This is already added once because it is part of the kernel package release name. Signed-off-by: Brian Behlendorf <[email protected]>
* Add the release component to headersBrian Behlendorf2012-01-1816-24/+24
| | | | | | | | | When the original build system code was added the release component was accidentally omited from the development header install path. This patch adds the missing path component so it's always clear exactly what release your compiling against. Signed-off-by: Brian Behlendorf <[email protected]>
* Allow GPT+EFI vdev replacement in boot pools.Darik Horn2012-01-181-0/+2
| | | | | | | | | | | | | | Commit zfsonlinux/zfs@57a4eddc4d5e1e6c10d8d7dcf87a9fc27398adcd allows the bootfs property to be set on any pool, but does not accommodate subsequent vdev changes. For example: # zpool replace rpool /dev/sda /dev/sdb operation not supported on this type of pool property 'bootfs' is not supported on EFI labeled devices For non-Solaris builds, disable the check that emits this error. Signed-off-by: Brian Behlendorf <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 07:50:33 +0000