Very interesting introduction

Btw. ajoeiam you're asking the wrong questions. You run a RAID array. Have you decided what filesystem are you going to use?

You either use the classic UFS with the GEOM framework to set up the RAID layer over the physical drives,
or you use ZFS which is combined volume manager and filesystem.

If you use ZFS this complete topic is moot as you don't have to predetermine your filesystem hierarchy.
If a directory in a filesystem starts to grow, you can just detach it to its own filesystem and set the quota.

You have to translate Linux LVM/RAID setup into UFS+GEOM or ZFS which has certainly more things to think of than whether to detach /var or not.

Pick what you want to use. If you can use ZFS, the partition layout issues are gone.
 
Btw. ajoeiam you're asking the wrong questions. You run a RAID array. Have you decided what filesystem are you going to use?

You either use the classic UFS with the GEOM framework to set up the RAID layer over the physical drives,
or you use ZFS which is combined volume manager and filesystem.

If you use ZFS this complete topic is moot as you don't have to predetermine your filesystem hierarchy.
If a directory in a filesystem starts to grow, you can just detach it to its own filesystem and set the quota.

You have to translate Linux LVM/RAID setup into UFS+GEOM or ZFS which has certainly more things to think of than whether to detach /var or not.

Pick what you want to use. If you can use ZFS, the partition layout issues are gone.
Actually NOT (with respect) - - - you are making a large assumption and in this case its quite incorrect.
None of the 7 partitions I listed are on the raid-10 array.
Instead each is on its own Raid-1 (mirrored if I'm recommembering the rong number - grin!) array.
The raid-10 array is what I use for long term storage - - - info is separate from any of the seven partitions.
Therefore UFS just wouldn't work.
Haven't used LVM either - - - just don't like more than one layer of software between my stuff and storage!
The raid-10 array is a very very separate question.
 
Would you please care to explain what these 3 statements mean?
TIA
For the 1st one, when I needed to delete local ports tree (by default, /usr/ports), deleting the whole tree causes fetched distfiles (upstream tarballs and so on) under /usr/ports/distfiles and built-and-saved packages under /usr/ports/packages, both of which are NOT parts of official ports tree and always created locally, to be deleted, too.
Making these 2 directories to be separate partition (UFS) or dataset (ZFS) allows these to be kept as-is on deletion by unmounting them before deletion.

This can happen when
  • switching from ports distribution of installation media to git
  • switching between git and gitup (git requires .git directory for managing the local repo, but gitup disallows the existence of .git directory)
  • FreeBSD project switches VCS from git to something others
  • severely broke the ports tree and need refreshing (if you're going to be a ports developer) from scratch
I've been bitten by 1st and 3rd (subversion to git at the moment) item, and at the first time I've moved the contents to outside of ports tree, delete ports tree, fetch fresh ports tree (at the moment, using cvsup), then restored moved ones AFTER creating and mounting dedicated partitions for them.


For the 2nd, just as described. Setting atime (means, accessed time) on causes writes even on reads (read is read access!) to update file / directory attributes. This causes severe slow down especially on spinning rust, and severe worn outs for SSDs, so strongly adviced to set only when really, really and really mandatory. If I recall correctly, /var/mail/ is the quite rare example that require atime=on. Another examples would be sensitive personal informations.


For the 3rd (last), ZFS can easily take snapshots, not limited to 1 per dataset, and can rollback to existing snapshot whenever wanted.
This allows testing easier. Take a snapshot for possibly affected datasets, test, if something goes wrong and want to go back to previous sane state, by rolling back to the snapshot. And affected directories are often limited, so making the affected directories to be dedicated dataset per directory helps, not to roll back unwanted parts of the pool.

And more, ZFS can send differences between 2 snapshots to previously cloned pool(s). No need to send the whole pool everytime.
This eases backups. And the wanted frequency of backups are usually different per directories.
 
Actually NOT (with respect) - - - you are making a large assumption and in this case its quite incorrect.

No I wasn't making any large assumptions, I just didn't catch the last reply you sent me, sorry about that.
Your choice is ZFS, point up from me :)

"Assumption" that you will do main fs on RAID is not important, the gist of my post was pick between UFS and ZFS so we can follow through in a direction.

AIUI ZFS allows one to set up a 'constrained' (ie max size of xxxx xxbytes) folder which seems to be at least similar in use.

postgresql, apache, likely nginx - - - not sure which others I have presently that I want to re-establish.
I have no idea on how things on freebsd (and zfs) are different than over in linux land so if you might
point me to a document on at least the above - - - that would be appreciated.

Yes I think ZFS is the great tool for your purpose and you should look into it, google is enough to get one started like :

The main thing is not looking at ZFS as "filesystem", I know this sounds wrong, but ZFS is not like other fs'es.
The "constrained folder", which is a totally correct definition of something like setting quota on NTFS filesystems' folder, doesn't apply here because, the ZFS filesystem is not fixed, bound to a partition on a hard drive, it is an internal segmentation of the ZFS pool. In turn the operating system does not boot from ZFS root partition but ZFS root pool, the partitions are not resized or reshuffled but pools are, if the backend physical hard disk space needs to increase/decrease etc.

All the filesystems live inside a pool, they share the data capacity of the pool unless capped by the quota.

I would recommend while you're still on Linux, do a default ZFS installation of FreeBSD inside a virtual machine to see the zfs tools running, I think a working system tells a thousand words more than any post or tutorial especially if you already have a good Linux experience.

I don't see any impediment why you couldn't use default ZFS installation and just detach some directories into filesystems and set quotas on them as you see them grow, like /var/www for nginx and apache. But why not run it in a VM first to see it in action.
 
Back
Top