summaryrefslogtreecommitdiffstats
path: root/sys/cddl
Commit message (Collapse)AuthorAgeFilesLines
* - zfs_zaccess() can handle VAPPEND too, so map V_APPEND to VAPPEND and callpjd2009-10-303-10/+23
| | | | | | | | | | | | | zfs_access() instead of vaccess() in this case as well. - If VADMIN is specified with another V* flag (unlikely) call both zfs_access() and vaccess() after spliting V* flags. This fixes "dirtying snapshot!" panic. PR: kern/139806 Reported by: Carl Chave <carl@chave.us> In co-operation with: jh MFC after: 3 days
* Correct some issues with zfs boot.rnoland2009-10-231-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Teach it to read gang blocks. (essentially untested) If you see "ZFS: gang block detected!", please let me know, so we can either remove the printf if it works, or fix it if it doesn't. - If multiple partitions exist on a disk, probe them all. We also need to reset dsk->start to 0 to read the right sector here. - With GPT, we can have 128 partitions. - If the bootfs property has ever been set on a pool it seems that it never goes away. zpool won't allow you to add to the pool with the bootfs property set. However, if you clear the property back to default we end up getting 0 for the object number and read a bogus block pointer and fail to boot. - Fix some error printfs. The printf in the loader is only capable of c,s and u formats. - Teach printf how to display %llu Reviewed by: dfr, jhb MFC after: 2 weeks
* Allow file system owner to modify system flags if securelevel permits.pjd2009-10-083-12/+17
| | | | MFC after: 3 days
* File system owner is when uid matches and jail matches.pjd2009-10-081-3/+2
| | | | MFC after: 3 days
* On FreeBSD it is enough to report provider removal when orphan event ispjd2009-10-071-20/+0
| | | | | | | received, we don't have to do it on every ENXIO error in I/O path. Solaris has no GEOM so they have to handle it in a less clean way. MFC after: 3 days
* Fix white-spaces.pjd2009-10-071-6/+6
| | | | MFC after: 3 days
* Fix situation where Mac OS X NFS client creates a file and when it triespjd2009-10-071-1/+17
| | | | | | | | | to set ownership and mode in the same setattr operation, the mode was overwritten by secpolicy_vnode_setattr(). PR: kern/118320 Submitted by: Mark Thompson <info-gentoo@mark.thompson.bz> MFC after: 3 days
* Prevent paging pressure from draining arc too muchkmacy2009-10-061-3/+6
| | | | | | - always drain arc if above arc_c_max - never drain arc if arc is below arc_c_max MFC after: 3 days
* Return EOPNOTSUPP instead of EINVAL when doing chflags(2) over an olddelphij2009-10-011-0/+4
| | | | | | | format ZFS, as defined in the manual page. Submitted by: pjd (response of my original patch but bugs are mine) MFC after: 3 days
* Handle cases where virtual (GFS) vnodes are referenced when doing forcedpjd2009-09-262-15/+22
| | | | | | | | | unmount. In that case we cannot depend on the proper order of invalidating vnodes, so we have to free resources when we have a chance. PR: kern/139062 Reported by: trasz MFC after: 3 days
* On lookup error VFS expects *vpp to be set to NULL, be sure to do that.pjd2009-09-261-0/+2
| | | | MFC after: 3 days
* Use traverse() function to find and return mount point's vnode instead ofpjd2009-09-261-3/+6
| | | | | | covered vnode when snapshot is already mounted. MFC after: 3 days
* - Don't depend on value returned by gfs_*_inactive(), it doesn't workpjd2009-09-261-13/+5
| | | | | | | | | well with forced unmounts when GFS vnodes are referenced. - Make other preparations to GFS for forced unmounts. PR: kern/139062 Reported by: trasz MFC after: 3 days
* Switch to fletcher4 as the default checksum algorithm. Fletcher2 was proven topjd2009-09-252-3/+103
| | | | | | | | be a bit weak and OpenSolaris also switched to fletcher4. PR: kern/139072 Reported by: Daniel Grund <bugs@dgrund.de> MFC after: 3 days
* Before calling vflush(FORCECLOSE) mark file system as unmounted so thepjd2009-09-242-1/+16
| | | | | | | | | | | | | | | | following vnops will fail. This is very important, because without this change vnode could be reclaimed at any point, even if we increased usecount. The only way to ensure that vnode won't be reclaimed was to lock it, which would be very hard to do in ZFS without changing a lot of code. With this change simply increasing usecount is enough to be sure vnode won't be reclaimed from under us. To be precise it can still be reclaimed but we won't be able to see it, because every try to enter ZFS through VFS will result in EIO. The only function that cannot return EIO, because it is needed for vflush() is zfs_root(). Introduce ZFS_ENTER_NOERROR() macro that only locks z_teardown_lock and never returns EIO. MFC after: 3 days
* Close race in zfs_zget(). We have to increase usecount first and thenpjd2009-09-241-9/+19
| | | | | | | check for VI_DOOMED flag. Before this change vnode could be reclaimed between checking for the flag and increasing usecount. MFC after: 3 days
* In VOP_SETACL(9) and VOP_GETACL(9), specifying wrong ACL type should resulttrasz2009-09-231-2/+2
| | | | in EINVAL, not EOPNOTSUPP.
* Restore BSD behaviour - when creating new directory entry use parent directorypjd2009-09-231-1/+1
| | | | | | | | | | gid to set group ownership and not process gid. This was overlooked during v6 -> v13 switch. PR: kern/139076 Reported by: Sean Winn <sean@gothic.net.au> MFC after: 3 days
* Purge namecache in the same place OpenSolaris does.pjd2009-09-202-6/+3
|
* Purge file system namecache when receiving incremental stream and rolling backpjd2009-09-171-0/+3
| | | | | | to it. MFC after: 3 days
* Purge namecache for the file system being rolled back, so it doesn't point atpjd2009-09-171-0/+3
| | | | | | | | invalid vnodes after the rollback resulting in EIO errors when trying to access files which are in the namecache. Reported by: des MFC after: 3 days
* Forced unmounts work just fine in my tests under heavy load. There mightpjd2009-09-151-5/+0
| | | | still be a problem, but it isn't worth a warning.
* We believe ZFS is ready for production use. Remove a warning about it beingpjd2009-09-151-2/+0
| | | | experimental. :)
* - Mount ZFS snapshots with MNT_IGNORE flag, so they are not visible in regularpjd2009-09-143-53/+36
| | | | | | | | | | df(1) and mount(8) output. This is a bit smilar to OpenSolaris and follows ZFS route of not listing snapshots by default with 'zfs list' command. - Add UPDATING entry to note that ZFS snapshots are no longer visible in mount(8) and df(1) output by default. Reviewed by: kib MFC after: 3 days
* Support both case: when snapshot is already mounted and when it is not yetpjd2009-09-131-5/+3
| | | | | | mounted. MFC after: 3 days
* Add missing \n.pjd2009-09-131-1/+1
| | | | Reported by: marck
* Work-around READDIRPLUS problem with .zfs/ and .zfs/snapshot/ directoriespjd2009-09-131-0/+14
| | | | | | | | | | | | | | | | | | by just returning EOPNOTSUPP. This will allow NFS server to fall back to regular READDIR. Note that converting inode number to snapshot's vnode is expensive operation. Snapshots are stored in AVL tree, but based on their names, not inode numbers, so to convert inode to snapshot vnode we have to interate over all snalshots. This is not a problem in OpenSolaris, because in their READDIRPLUS implementation they use VOP_LOOKUP() on d_name, instead of VFS_VGET() on d_fileno as we do. PR: kern/125149 Reported by: Weldon Godfrey <wgodfrey@ena.com> Analysis by: Jaakko Heinonen <jh@saunalahti.fi> MFC after: 3 days
* When zfs.ko is compiled with debug, make sure that znode and vnode point atpjd2009-09-133-3/+22
| | | | | | each other. MFC after: 3 days
* Extend scope of the z_teardown_lock lock for consistency and "just in case".pjd2009-09-131-2/+3
| | | | MFC after: 3 days
* Be sure not to overflow struct fid.pjd2009-09-131-0/+2
| | | | MFC after: 3 days
* There is a bug where mze_insert() can trigger an assert() of insertingpjd2009-09-131-5/+16
| | | | | | | | | | | the same entry twice. This bug is not fixed yet, but leads to situation where when try to access corrupted directory the kernel will panic. Until the bug is properly fixed, try to recover from it and log that it happened. Reported by: marck OpenSolaris bug: 6709336 MFC after: 3 days
* - Protect reclaim with z_teardown_inactive_lock.pjd2009-09-122-5/+29
| | | | | | | | | | - Be prepared for dbuf to disappear in zfs_reclaim_complete() and check if z_dbuf field is NULL - this might happen in case of rollback or forced unmount between zfs_freebsd_reclaim() and zfs_reclaim_complete(). - On forced unmount wait for all znodes to be destroyed - destruction can be done asynchronously via zfs_reclaim_complete(). MFC after: 1 week
* Tighten up the check for race in zfs_zget() - ZTOV(zp) can not only containpjd2009-09-121-2/+10
| | | | | | | | | NULL, but also can point to dead vnode, take that into account. PR: kern/132068 Reported by: Edward Fisk" <7ogcg7g02@sneakemail.com>, kris Fix based on patch from: Jaakko Heinonen <jh@saunalahti.fi> MFC after: 1 week
* Only log successful commands! Without this fix we log even unsuccessfulpjd2009-09-081-2/+4
| | | | | | | | commands executed by unprivileged users. Action is not really taken, but it is logged to pool history, which might be confusing. Reported by: Denis Ahrens <denis@h3q.com> MFC after: 3 days
* We don't export individual snapshots, so mnt_export field in snapshot'spjd2009-09-081-0/+23
| | | | | | | mount point is NULL. That's why when we try to access snapshots over NFS use mnt_export field from the parent file system. MFC after: 1 week
* When we automatically mount snapshot we want to return vnode of the mount pointpjd2009-09-081-3/+19
| | | | | | | from the lookup and not covered vnode. This is one of the fixes for using .zfs/ over NFS. MFC after: 1 week
* On FreeBSD we don't have to look for snapshot's mount point,pjd2009-09-081-0/+6
| | | | | | because fhtovp method is already called with proper mount point. MFC after: 1 week
* Call ZFS_EXIT() after locking the vnode.pjd2009-09-081-3/+1
| | | | MFC after: 1 week
* Lock Giant around vn_open_cred().kib2009-09-081-2/+4
| | | | | | | | Remove innocent unnecessary call to NDFREE(). Reported by: marcel Reviewed and tested by: pjd MFC after: 3 days
* Fix reference count leak for a case where snapshot's mount point is updated.pjd2009-09-081-0/+7
| | | | | | | | | | | | | | | | Such situation is not supported. This problem was triggered by something like this: # zpool create tank da0 # zfs snapshot tank@snap # cd /tank/.zfs/snapshot/snap (this will mount the snapshot) # cd # mount -u nosuid /tank/.zfs/snapshot/snap (refcount leak) # zpool export tank cannot export 'tank': pool is busy MFC after: 1 week
* If we have to use avl_find(), optimize a bit and use avl_insert() instead ofpjd2009-09-071-5/+10
| | | | | | avl_add() (the latter is actually a wrapper around avl_find() + avl_insert()). Fix similar case in the code that is currently commented out.
* When snapshot mount point is busy (for example we are still in it)pjd2009-09-071-1/+9
| | | | | | | | | | | | | | | | we will fail to unmount it, but it won't be removed from the tree, so in that case there is no need to reinsert it. This fixes a panic reproducable in the following steps: # zfs create tank/foo # zfs snapshot tank/foo@snap # cd /tank/foo/.zfs/snapshot/snap # umount /tank/foo panic: avl_find() succeeded inside avl_add() Reported by: trasz MFC after: 3 days
* Enable NFSv4 ACL support in ZFS.trasz2009-09-071-6/+31
| | | | Reviewed by: pjd
* Defer thread start until we set priority.pjd2009-09-071-1/+3
| | | | | Reviewed by: kib MFC after: 3 days
* Don't recheck ownership on update mount. This will eliminate LOR betweenpjd2009-09-071-5/+6
| | | | | | | | vfs_busy() and mount mutex. We check ownership in vfs_domount() anyway. Noticed by: kib Reviewed by: kib MFC after: 1 week
* - Avoid holding mutex around M_WAITOK allocations.pjd2009-09-071-6/+26
| | | | | | - Add locking for mnt_opt field. MFC after: 1 week
* Prevent the line from wrapping.trasz2009-09-071-1/+1
|
* Changing provider size is not really supported by GEOM, but doing so whenpjd2009-09-071-5/+16
| | | | | | | | | | | provider is closed should be ok. When administrator requests to change ZVOL size do it immediately if ZVOL is closed or do it on last ZVOL close. PR: kern/136942 Requested by: Bernard Buri <bsd@ask-us.at> MFC after: 1 week
* bzero() on-stack argument, so mutex_init() won't misinterpret that thepjd2009-09-071-0/+1
| | | | | | | | lock is already initialized if we have some garbage on the stack. PR: kern/135480 Reported by: Emil Mikulic <emikulic@gmail.com> MFC after: 3 days
* Improve wording.trasz2009-09-051-4/+8
| | | | Discussed with: pjd, cperciva, rink, wkoszek and des, in order of appearance.
OpenPOWER on IntegriCloud