Re: Hammer FS: imposing a size limit on PFS?
: :He, : :* Matthew Dillon wrote: :> :> The idea with HAMMER is you just create one big filesystem and use the :> PFS functionality to break it up into separate management domains. :> Currently a size limit may not be placed on a PFS. : :This raises an important question: what to do if one uses HAMMER on a :multi user box? It should be possible for a malicious user to fill up :his $HOME on the /home PFS and thus blow the fs up, or? Correct me if :I'm wrong. If I'm right what is the policy for admins using HAMMER on a :machine with a lot of user shells? : :Regards : : Matthias : :PS: Someone interested to hack quota support for HAMMER? :) Basically we would need a quota system in the kernel layer that works for all filesystems, rather then the current VFS-specific quota system. -Matt Matthew Dillon
Re: Hammer FS: imposing a size limit on PFS?
He, * Matthew Dillon wrote: > > The idea with HAMMER is you just create one big filesystem and use the > PFS functionality to break it up into separate management domains. > Currently a size limit may not be placed on a PFS. This raises an important question: what to do if one uses HAMMER on a multi user box? It should be possible for a malicious user to fill up his $HOME on the /home PFS and thus blow the fs up, or? Correct me if I'm wrong. If I'm right what is the policy for admins using HAMMER on a machine with a lot of user shells? Regards Matthias PS: Someone interested to hack quota support for HAMMER? :)
Re: Hammer FS: imposing a size limit on PFS?
Matthew Dillon wrote: Our installer support for HAMMER isn't advanced enough yet. What we really want is a UFS /boot, swap, and then a HAMMER root that covers everything else. I would (and have) taken that a step farther. 'once upon a time' '/usr' was not part of the core essential. It really was 'userland' Long since, far too many of the *system's* 'needful things' in the way of binary and libs migrated there. Recall my push to get a decent static-compiled editor into the root partition so we could at least edit a FUBAR'ed /etc/rc.conf w/o having to manually mount a (potentially damaged) /usr. 'These days' one gains a bit of respect for NetBSD / OpenBSD plutting things into /usr/pkg rather than /usr/local, if only to keep them out of the way of 'real userland' - and even looks yearningly at Linux use of '/opt' Reality is that a 'healthy' system needs '/usr' (libs and binaries) and '/var' (pidfiles, logs, and spools) to be mounted more or less 'at all costs'. Ergo, one wants to push anything that really IS userland and user-app, or 'production use' specific out into bespoke mounts. True whether the box is to be used for familiarization, learning, experimenting, OR 'production'. And regardless of fs chosen The idea with HAMMER is you just create one big filesystem and use the PFS functionality to break it up into separate management domains. Currently a size limit may not be placed on a PFS. -Matt I want my 'core' to be as damage-resistant as can be. So long as it IS such, and can boot and mount rapidly and respond to console - better yet ssh from afar - I have the wherewithal to manage, repair, or even nuke and reinstall - all the rest. Ergo, absent a 'netboot' or flash/USB boot - I submit: 'Best Current Practice'; Minimum with one device: - A modest 'slice' for the OS install, partioned and UFS, OR 'shared' with hammer. - One or more SEPARATE partons if not SLICES for hammer-as-bulk storage, application support, etc. IOW - not entangled in any way with '/usr', '/var'. You can wipe it and start over over-the-wire, as the 'core' is isolated. Better yet - multiple devices, where second and subsequent devices where hammer owns the entire device. If we cannot isolate and protect the 'core' within a hammer PFS, then we should not put it into the same PFS 'family' and open it to overflow or damage. JM-scar-tissue's-2CW - but we have found this 'safe' from CP/M 1.X onward. Logs and spool aside, 'core' has slow or no rate of change. Bill
Re: Hammer FS: imposing a size limit on PFS?
Thank you very much! Kind regards, Jurij Kovacic Matthew Dillon wrote: Our installer support for HAMMER isn't advanced enough yet. What we really want is a UFS /boot, swap, and then a HAMMER root that covers everything else. The idea with HAMMER is you just create one big filesystem and use the PFS functionality to break it up into separate management domains. Currently a size limit may not be placed on a PFS. -Matt
Re: Hammer FS: imposing a size limit on PFS?
Our installer support for HAMMER isn't advanced enough yet. What we really want is a UFS /boot, swap, and then a HAMMER root that covers everything else. The idea with HAMMER is you just create one big filesystem and use the PFS functionality to break it up into separate management domains. Currently a size limit may not be placed on a PFS. -Matt
Re: Hammer FS: imposing a size limit on PFS?
Thank you very much for your reply. Matthias Schmidt wrote: You do not have to take care about the sizes of the PFS. They are all on top of the native HAMMER partition so they share the capacity. There was a very good post from Matt on PFS some days ago ... so have a look in the archives. What I found confusing was that the installer states that "There is no need to create separate slices for /var, /home ..." on account of PFS. If PFSs /var, /home, / ... share the same native HAMMER partition then, for example, a malicious user could cause the whole system to run out of disk space by placing/creating a large file in his home directory. Likewise, an overgrown log file residing in /var could cause the same "side effects". This is why I wanted to implement the following partitioning scheme: / 256MB swap 4G /usr 5G /var 5G /home 2G /jails 50G but found that 256MB..or even 1G was not enough for root partition, since the installer ran out of disk space. This prompted my question: how large should the root partition for the install? Kind regards, Jurij Kovacic
Re: Hammer FS: imposing a size limit on PFS?
Hi, * Jurij Kovacic wrote: > Hello fellow DragonFly users, > > I have a newbie question: > DragonFly 2.2 installer automatically creates PFSs for /home, /var, /usr > and /tmp. Is there a way to limit the sizes of respective PFSs or do > you have to create separate slices to acomplish this? You do not have to take care about the sizes of the PFS. They are all on top of the native HAMMER partition so they share the capacity. There was a very good post from Matt on PFS some days ago ... so have a look in the archives. > On a side note - what would be the best source of information relating > to Hammer, apart from http://www.dragonflybsd.org/hammer/ and man pages? Postings to the mailing lists and there are some presentations/podcasts available. Regards Matthias
Hammer FS: imposing a size limit on PFS?
Hello fellow DragonFly users, I have a newbie question: DragonFly 2.2 installer automatically creates PFSs for /home, /var, /usr and /tmp. Is there a way to limit the sizes of respective PFSs or do you have to create separate slices to acomplish this? I would like to use DragonFly OS for a test web site, so initially, I wanted to implement the following partitioning scheme, / 256MB swap 4G /usr 5G /var 5G /home 2G /jails 50G but it seems the installer has problems if the root partition is too small (say 256MB). What would be the reccomended size for root partition then? On a side note - what would be the best source of information relating to Hammer, apart from http://www.dragonflybsd.org/hammer/ and man pages? Kind regards, Jurij Kovacic
