|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
Re: conf/120228: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes managementSynopsis: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes management
State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: ¶ro 9 wrz 2009 18:14:21 UTC State-Changed-Why: Thank you for your patch, but I already committed something along those line. rc.d/zfs script was broken and there is now also rc.d/zvol script. It was created so ZVOL-based file systems can be mounted from /etc/fstab. Using ZVOL property to setup swap was intended - ZFS file systems are also not mounted from /etc/fstab. All in all using ZVOL for swap is unreliable anyway. Responsible-Changed-From-To: freebsd-rc->pjd Responsible-Changed-By: pjd Responsible-Changed-When: ¶ro 9 wrz 2009 18:14:21 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=120228 _______________________________________________ freebsd-rc@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..." |
|
|
Re: conf/120228: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes managementHi,
On Wed, Sep 9, 2009 at 8:31 PM, <pjd@...> wrote: > Synopsis: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes management > > State-Changed-From-To: open->closed > State-Changed-By: pjd > State-Changed-When: śro 9 wrz 2009 18:14:21 UTC > State-Changed-Why: > Thank you for your patch, but I already committed something along those line. We're probably speaking of SVN changeset 195938 ? > rc.d/zfs script was broken and there is now also rc.d/zvol script. It was > created so ZVOL-based file systems can be mounted from /etc/fstab. > Using ZVOL property to setup swap was intended - ZFS file systems are also not > mounted from /etc/fstab. All in all using ZVOL for swap is unreliable anyway. While I do understand the "unreliable" part I still fail to understand why do we need to complicate matters with ZFS user property signatures to mount ZFS swap volumes instead of the traditional /etc/fstab way -- is there a concrete reason for this (besides said reliability) ? Thanks, Adrian Penisoara EnterpriseBSD _______________________________________________ freebsd-rc@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..." |
|
|
Re: conf/120228: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes managementOn Fri, Sep 11, 2009 at 12:34:27PM +0200, Adrian Penisoara wrote:
> Hi, > > On Wed, Sep 9, 2009 at 8:31 PM, <pjd@...> wrote: > > Synopsis: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes management > > > > State-Changed-From-To: open->closed > > State-Changed-By: pjd > > State-Changed-When: śro 9 wrz 2009 18:14:21 UTC > > State-Changed-Why: > > Thank you for your patch, but I already committed something along those line. > > We're probably speaking of SVN changeset 195938 ? > > rc.d/zfs script was broken and there is now also rc.d/zvol script. It was > > created so ZVOL-based file systems can be mounted from /etc/fstab. > > Using ZVOL property to setup swap was intended - ZFS file systems are also not > > mounted from /etc/fstab. All in all using ZVOL for swap is unreliable anyway. > > While I do understand the "unreliable" part I still fail to understand > why do we need to complicate matters with ZFS user property signatures > to mount ZFS swap volumes instead of the traditional /etc/fstab way -- > is there a concrete reason for this (besides said reliability) ? The idea is to keep things consistent. You can still use /etc/fstab to put swap on ZVOLs, no? You can also set mountpoint property for file system to 'legacy' and then you can mount it from to /etc/fstab too. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@... http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! |
|
|
Re: conf/120228: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes managementHi,
On Fri, Sep 11, 2009 at 2:20 PM, Pawel Jakub Dawidek <pjd@...> wrote: [...] >> >> We're probably speaking of SVN changeset 195938 ? > > Yes. > >> > rc.d/zfs script was broken and there is now also rc.d/zvol script. It was >> > created so ZVOL-based file systems can be mounted from /etc/fstab. >> > Using ZVOL property to setup swap was intended - ZFS file systems are also not >> > mounted from /etc/fstab. All in all using ZVOL for swap is unreliable anyway. >> >> While I do understand the "unreliable" part I still fail to understand >> why do we need to complicate matters with ZFS user property signatures >> to mount ZFS swap volumes instead of the traditional /etc/fstab way -- >> is there a concrete reason for this (besides said reliability) ? > > The idea is to keep things consistent. You can still use /etc/fstab to > put swap on ZVOLs, no? You can also set mountpoint property for file Actually using /etc/fstab for zvol swap is not quite working in the current setup since /etc/rc.d/swap1 does not automatically swapoff upon shutdown which makes 'zvol stop' attempt to close the (swap) volume(s) while still in use. I guess 'zfs volfini' should be triggered by a shutdown hook similarly to what geom(4) classes are using. I see Guido committed a swapoff hook in changeset 189624 (similar to what I suggested in my initial PR) but immediately backed it out the next day. Funny thing is that this swapoff hook flip-flopped over time, see changesets 135389, 137255. Is there a reason not to have the swap devices automatically unmounted from /etc/swap1 upon shutdown ? > system to 'legacy' and then you can mount it from to /etc/fstab too. > Perhaps not the best idea: what if I export and then import a zpool from one system to another -- then I will have some swap volumes automatically mounted upon boot, breaking POLA. You can argue that ZFS filesystems will also be automatically mounted too, but this is a consistent behavior across different OSes while the discussed swap volume automount is FreeBSD specific. Sorry to insist, but I still think we should we keep it simple... Unless people are already using/depending on this feature. Regards, Adrian. _______________________________________________ freebsd-rc@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..." |
|
|
Re: conf/120228: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes managementOn Fri, Sep 11, 2009 at 05:19:41PM +0200, Adrian Penisoara wrote:
> Actually using /etc/fstab for zvol swap is not quite working in the > current setup since /etc/rc.d/swap1 does not automatically swapoff > upon shutdown which makes 'zvol stop' attempt to close the (swap) > volume(s) while still in use. > I guess 'zfs volfini' should be triggered by a shutdown hook > similarly to what geom(4) classes are using. > > I see Guido committed a swapoff hook in changeset 189624 (similar to > what I suggested in my initial PR) but immediately backed it out the > next day. Funny thing is that this swapoff hook flip-flopped over > time, see changesets 135389, 137255. > > Is there a reason not to have the swap devices automatically > unmounted from /etc/swap1 upon shutdown ? There really no point in removing swap on shutdown (it could still be a good idea to do it when administrator executes /etc/rc.d/swap1 stop). We unmount file systems on shutdown, because we want to keep them consistent. There is no need to keep swap consistent, as the data will be useless after reboot anyway. All in all running swapoff at shutdown time increases reboot time and introduce possibility of failure (I think the kernel can panic if there is no enough memory to move everything out of the swap, but I might be wrong here). There are some tricky cases too. For example: # truncate -s 1g /swap.img # mdconfig -a -f /swap.img # swapon /dev/md0 Now if we don't remove swap we won't be able to unmount file system in non-forcible way. > > system to 'legacy' and then you can mount it from to /etc/fstab too. > > > > Perhaps not the best idea: what if I export and then import a zpool > from one system to another -- then I will have some swap volumes > automatically mounted upon boot, breaking POLA. > > You can argue that ZFS filesystems will also be automatically mounted > too, but this is a consistent behavior across different OSes while the > discussed swap volume automount is FreeBSD specific. > > Sorry to insist, but I still think we should we keep it simple... > Unless people are already using/depending on this feature. /etc/fstab. I'm just giving an option. I'll think about it a bit more and talk to some people what they think about this and I'll get back to you. Maybe this property is indeed redundant, but I don't want to make any rush decisions. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@... http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! |
|
|
Re: conf/120228: [zfs] [patch] Split ZFS volume startup / ease ZFS swap volumes managementHi,
On Fri, Sep 11, 2009 at 5:41 PM, Pawel Jakub Dawidek <pjd@...> wrote: > On Fri, Sep 11, 2009 at 05:19:41PM +0200, Adrian Penisoara wrote: >> Actually using /etc/fstab for zvol swap is not quite working in the >> current setup since /etc/rc.d/swap1 does not automatically swapoff >> upon shutdown which makes 'zvol stop' attempt to close the (swap) >> volume(s) while still in use. >> I guess 'zfs volfini' should be triggered by a shutdown hook >> similarly to what geom(4) classes are using. >> >> I see Guido committed a swapoff hook in changeset 189624 (similar to >> what I suggested in my initial PR) but immediately backed it out the >> next day. Funny thing is that this swapoff hook flip-flopped over >> time, see changesets 135389, 137255. >> >> Is there a reason not to have the swap devices automatically >> unmounted from /etc/swap1 upon shutdown ? > > The answer is simple: we don't want swapoff to fail. > > There really no point in removing swap on shutdown (it could still be a > good idea to do it when administrator executes /etc/rc.d/swap1 stop). > We unmount file systems on shutdown, because we want to keep them > consistent. There is no need to keep swap consistent, as the data will > be useless after reboot anyway. > > All in all running swapoff at shutdown time increases reboot time and > introduce possibility of failure (I think the kernel can panic if there > is no enough memory to move everything out of the swap, but I might be > wrong here). Some (if not most) of the Linux distros do turn off swap at shutdown time and AFAIK they did not encounter issues. One more white ball to do the same. > > There are some tricky cases too. For example: > > # truncate -s 1g /swap.img > # mdconfig -a -f /swap.img > # swapon /dev/md0 > > Now if we don't remove swap we won't be able to unmount file system in > non-forcible way. Hmm, I guess we still need to "mdconfig -d" to have a clean filesystem unmount anyway... > >> > system to 'legacy' and then you can mount it from to /etc/fstab too. >> > >> >> Perhaps not the best idea: what if I export and then import a zpool >> from one system to another -- then I will have some swap volumes >> automatically mounted upon boot, breaking POLA. >> >> You can argue that ZFS filesystems will also be automatically mounted >> too, but this is a consistent behavior across different OSes while the >> discussed swap volume automount is FreeBSD specific. >> >> Sorry to insist, but I still think we should we keep it simple... >> Unless people are already using/depending on this feature. > > Please understand that I don't want to disallow swap configuration from > /etc/fstab. I'm just giving an option. Sure. > > I'll think about it a bit more and talk to some people what they think > about this and I'll get back to you. Maybe this property is indeed > redundant, but I don't want to make any rush decisions. > OK, waiting your feedback. Thanks, Adrian Penisoara EnterpriseBSD _______________________________________________ freebsd-rc@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..." |
| Free embeddable forum powered by Nabble | Forum Help |