On Wed, Dec 4, 2013 at 1:03 PM, Cassandra von Ahrcanburg < [email protected]> wrote:
> > > Keeping the history is also a nice feature that is not available in > > ZFS. It's sort of built-in backup. This needs some extra space, > > especially if a lot of files are changed very often. > > This is cold storage, so I would probably deactivate this feature > anyway - or at least reduce it. > If you'll only ever have one version of the file on disk, history won't help much, but if there's any chance a user will come up and say, "I scrambled this one file/set of files/whole directory; can I get yesterday's version?", it makes it very easy to fix. a similar example: I managed several times to accidentally delete all the pkgsrc binaries for a given DragonFly release when trying to sync over a new build. 12,000 or so packages, gone. I was able to copy them all back into place because of Hammer. > Both. As written before, this is cold storage and things will usually > not get removed, but instead, the archive will tend to grow. The > problem is, that I can't really say where. So setting a mount point in > a good position within the archives directory tree is near to > impossible. What I have done until now (with UFS) is to give each drive > a mount point outside of the archive. Beside all of these there is also > a directory tree (without files) of for the archive. Then I connect the > last directory level with smylinks to the tree. This way, when I add a > drive, adding its contents to the tree is a matter of clevis, but in > terms of skill, rather trivial. > DragonFly's mount_null works quite well, so you can use that to arbitrarily place drives. That may or may not make your life less complicated. > Just to be sure: In this context a volume could be a physical drive. So > creating a single fs over both ad1 and ad2 is a bad idea. I can > understand that, because this constellation would be something like a > RAID0. If one drive dies, all data is lost. If however ad1 and ad2 are > combined to a single volume either with vinum oder LVM, creating a > hammer on that would be ok. > I'm pretty sure that is correct - with the caveat that I haven't tried it.
