UFS SUJ for HDD

IIRC (but I might be wrong), file-system journaling is there to help you recover faster after system freeze or sudden/unexpected restart/shutdown. SSDs are fast and have low latency, fsck(8) is quick to finish; not so with hard drives, especially with large-capacity ones, or filled with large number of files.

If you have a journal, pending changes on a file system can be applied or rolled-back faster. Otherwise a fsck should scan every file-system object to check for corruption, basically walk thru all directories and files, meaning lots of mostly random I/O. That being said, I had cases, where journal were not enough and a manual fsck were still necessary after system crash.

What is your system's purpose? Desktop? (What kind of) Server?
 
Bobi B. my system's purpose is to learn programming and to do basic desktop tasks.
It will be a "entire disk" installation in a laptop's 932GB HDD, so is it recommended to turn on SUJ?
 
Then I would suggest you to enable soft updates and journaling, and to create separate / (root, 1G+), /usr (20G+), /var (10G+) and /tmp (10G+) partitions, and larger one for /usr/home. Add another one for /usr/jails, if you plan to use jail(8).

If you're into kernel programming test via bhyve(8) or VMs, otherwise you risk file-system corruption each time you test your code.
 
pensador_13 said:
Are /var (1G) and /tmp (1G) not good sizes?
Click to expand...
Lots of things are inside /var (including log and temporary files, including freebsd-update(8), cached downloaded binary packages, port updates, or databases, if you go this way), and lots of programs use /tmp for various purposes.

Here is one of office's development VMs (BTW du command ran for several minutes, but /usr/obj contains compiled kernel and a nanobsd image):
Code: 
# du -sh /usr /var
 13G    /usr
2.5G    /var

And that box does not run X.
 
pensador_13 said:
What is the difference between /tmp and tmpfs?
Edit: This answers my question.
Click to expand...

I've always used a ramdisk for temporary files ever since the good old days of MS-DOS (my uncle had set TMP to reside on a Turbodisk drive) and it's really a bless to speed things up, unless you're low in physical RAM and want to save the maximum possible for standard user processes :)

I would advise against referring to the Arch wiki unless for quick tips about configuring specific programs. It's a common practice in Linux communties to address it as 'the official UNIX reference', whereas it's just an appendix of articles, often redundant and sometimes contradictory, outdated or mistaken, written by different users, with different competence, opinions, targets, and and different confidence with English language. There's not an official way about how to write a Arch wiki page and quality check in not that strict outside pages related to pacman, installation and Arch Linux in general. That wiki often doesn't teach users how to deal with their system, rather it often suggests a list of commands, script and conf files to blindly copy and paste, ad this results in all Linux users adopting the same configuration as the wiki author of interest, which isn't necessarily th best, the most secure, the most up to date and easiest one.

There are soo many official wikis available online for this or that specific programs, while for smaller utilities the are Github READMEs and docs. Besides those, FreeBSD provides the handbook, the wiki, pkg-messages and samples, and an awesome database of exhaustive man pages. In this particular case a quick look to tmpfs(5) would have been more than enough, especially considering FreeBSD's tmpfs is different from Linux' ;)
 
Sensucht94 said:
I've always used a ramdisk for temporary files ever since the good old days of MS-DOS (my uncle had set TMP to reside on a Turbodisk drive) and it's really a bless to speed things up, unless you're low in physical RAM and want to save the maximum possible for standard user processes :)

I would advise against referring to the Arch wiki unless for quick tips about configuring specific programs. It's a common practice in Linux communties to address it as 'the official UNIX reference', whereas it's just an appendix of articles, often redundant and sometimes contradictory, outdated or mistaken, written by different users, with different competence, opinions, targets, and and different confidence with English language. There's not an official way about how to write a Arch wiki page and quality check in not that strict outside pages related to pacman, installation and Arch Linux in general. That wiki often doesn't teach users how to deal with their system, rather it often suggests a list of commands, script and conf files to blindly copy and paste, ad this results in all Linux users adopting the same configuration as the wiki author of interest, which isn't necessarily th best, the most secure, the most up to date and easiest one.

There are soo many official wikis available online for this or that specific programs, while for smaller utilities the are Github READMEs and docs. Besides those, FreeBSD provides the handbook, the wiki, pkg-messages and samples, and an awesome database of exhaustive man pages. In this particular case a quick look to tmpfs(5) would have been more than enough, especially considering FreeBSD's tmpfs is different from Linux' ;)
Click to expand...
After I posted #8, I immediately searched in tmpfs(5), FreeBSD's wiki and FreeBSD's forums :)
Thank you for the advice ;)
 
You must log in or register to reply here.
Back
Top