Re: Hammer pruning and pfs
:Hi, : :it's unclear to me whether pruning works locally to a PFS or not. : :Say I have a snapshots directory with links to PFS#1, e.g. : : /pfs1/snapshots : snap1 -> /pfs1/@0x : snap2 -> /pfs1/@0x : :and I do a : : hammer prune /pfs1/snapshots : :will it just prune the PFS#1 accoring to the softlinks, or :will it prune the whole Hammer filesystem using the softlinks. : :My understanding is that each PFS can be pruned separatly (otherwise :mirroring using per-mirror retention policies will not work). :But then, if one has multiple PFS, one has to maintain multiple :snapshots for each PFS, even if the transaction id of the snapshot :is global to the whole Hammer filesystem. : :Regards, : : Michael Yes. The actual pruning and reblocking ioctl's include parameters for specifying the PFS. The hammer prune and reblock commands actually test whether you are specifying a PFS softlink and figure out which PFS you are referencing. Theoretically just that PFS should be reblocked or pruned. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: cpdup will silently overwrite pfs
:Hi, : :I just noticed that the following: : : hammer pfs-master /hammer : cpdup /something /hammer : :will not behave as I initially assumed. : :I will not copy the contents of /adirectory into :the pfs /hammer. Instead, it will remove the PFS symlink /hammer :and create a directory /hammer. : :So the following: : : hammer pfs-status /hammer : :will show PFS#0 (the root PFS) instead of the newly created. :.. Yah, because PFS's are just softlinks. I think the same mount_null trick will solve this problem too. -Matt :BTW, now that I moved my 40GB into a directory on the root PFS instead :of PFS #1, can I simply "mv" it to PFS #1? I assume I can just do that. No, you can't. 'mv' may not fail, but it will be forced to copy the files instead of rename them. :2nd BTW: I have now a "/" PFS and a "/data" PFS which I'd like to mirror :separately. I assume that when I mirror "/", it will not include the :"/data" PFS. Is that correct? Correct. Reblocking, pruning, and mirroring should work per-PFS. Note: This also means you need to prune and reblock each pfs independantly. :Nevertheless, hammer and cpdup are extremely practical and great tools, :I'd never ever want to miss again. : :Regards, : : Michael -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Hammer pfs permissions
:Hi, : :It doesn't seem to be possible to assign permissions :(like 1777 for /tmp) to pseudo-filesystems: : : hammer pfs-master /tmp : chmod 1777 /tmp : ls -la /tmp : # still shows "lrwxr-xr-x" for /tmp : :Regards, : : Michael Softlinks have traditionally had this problem. I think what we really need to do is make PFS's mountable with the mount command. There is a workaround... use mount_null to mount the PFS: mount_null /pfs1 /tmp cd /tmp chmod 1777 /tmp -Matt Matthew Dillon <[EMAIL PROTECTED]>
Hammer pfs permissions
Hi, It doesn't seem to be possible to assign permissions (like 1777 for /tmp) to pseudo-filesystems: hammer pfs-master /tmp chmod 1777 /tmp ls -la /tmp # still shows "lrwxr-xr-x" for /tmp Regards, Michael
Hammer pruning and pfs
Hi, it's unclear to me whether pruning works locally to a PFS or not. Say I have a snapshots directory with links to PFS#1, e.g. /pfs1/snapshots snap1 -> /pfs1/@0x snap2 -> /pfs1/@0x and I do a hammer prune /pfs1/snapshots will it just prune the PFS#1 accoring to the softlinks, or will it prune the whole Hammer filesystem using the softlinks. My understanding is that each PFS can be pruned separatly (otherwise mirroring using per-mirror retention policies will not work). But then, if one has multiple PFS, one has to maintain multiple snapshots for each PFS, even if the transaction id of the snapshot is global to the whole Hammer filesystem. Regards, Michael
Re: [ANNOUNCEMENT] The pkgsrc-2008Q2 Branch
On Sun, Jul 27, 2008 at 07:21:21PM -0400, Constantine A. Murenin wrote: > Or like `pkg_add -u` on OpenBSD? :-) When did you last read the pkg_add man page coming with pkgsrc? :) Joerg
Re: cpdup will silently overwrite pfs
Michael Neumann schrieb: Hi, I just noticed that the following: hammer pfs-master /hammer cpdup /something /hammer will not behave as I initially assumed. I will not copy the contents of /adirectory into s/adirectory/something/ ;-)
cpdup will silently overwrite pfs
Hi, I just noticed that the following: hammer pfs-master /hammer cpdup /something /hammer will not behave as I initially assumed. I will not copy the contents of /adirectory into the pfs /hammer. Instead, it will remove the PFS symlink /hammer and create a directory /hammer. So the following: hammer pfs-status /hammer will show PFS#0 (the root PFS) instead of the newly created. So users should be warned when using cpdup together with PFS. Maybe we can do something about it (e.g. introducing a warning into cpdup). It's easy to recreate the original PFS if you know it's number (#1 in my case): ln -s "@@0x:1" /hammer Or maybe it's wise to let hammer pfs-master/slave do a "chflags noschg" by default on the symlink? BTW, now that I moved my 40GB into a directory on the root PFS instead of PFS #1, can I simply "mv" it to PFS #1? I assume I can just do that. 2nd BTW: I have now a "/" PFS and a "/data" PFS which I'd like to mirror separately. I assume that when I mirror "/", it will not include the "/data" PFS. Is that correct? Nevertheless, hammer and cpdup are extremely practical and great tools, I'd never ever want to miss again. Regards, Michael