yes.I'll probably do as denta proposed.It was good to learn about hier and daily .. although I'm still clueless about setting a personalized daily.local for that purpose (regardless of its being a bad idea) .. should I just comment out lines in /etc/daily :
next_part "Removing scratch and junk files:"
........
........

As a general administrative guideline, it is NEVER a good idea to change the functional design of the OS unless you fully understand the implications of your change. You do not.

Since you asked us for our opinion on whether it is advisable for you to alter the OS's function rather than use it as designed.... I must answer NO, it is not advisable. A) It is not best practice. B) There are alternatives we've already mentioned, such as /var/tmp or mounting a standard filesystem for your non-temporary files. C) You have not demonstrated via this forum that you have sufficient knowledge, skill, or self-reliance to manage the customization and any unforeseen operational impacts that may arise.

Last edited by jggimi; 3rd May 2012 at 08:04 PM.
Reason: typos, clarity

daemonfowl, I suspect you are seeing in the responses received thus far that a series of poor decisions are being made, and continuing down this path is going to lead to even larger problems.

You need to take a step back, & consider better alternatives. You also need to identify the core problem.

I have no idea how big this hard drive is, but allocating 19GB to a partition for /tmp seems inordinately large. Maybe this comes from the automatic partitioning the installer chose, or maybe this comes from choices you manually made. Section 4.6.4 of the FAQ will give some ideas to how much space should be allocated, however, there can be a huge debate over what size any particular partition needs to be. The true answer comes with identifying usage patterns & adjust sizes in the next fresh install to fit the use of the system, but a recommendation jggimi frequently makes is to just make one large partition for the entire system until you have a better idea as to how much space needs to be allocated for multiple partitions.

/tmp should not be used for storage. Yes, the eradication of /tmp at each boot-up can be changed, but the use case this addresses is situations where either erasing consumes too much time, or erasing adversely affects the lifetime of the media. I can only guess that you don't have space elsewhere for whatever you are storing, & so you have starting using /tmp as a poor, but expedient substitute.

The simple fact is that you need to back up your files & do a fresh install, changing the partition sizes to either one huge partition, or adjust the sizes to better values until you have a better perspective as to that the new adjustment needs to be.

Don't think you are going to get this right in one pass. You won't. Nobody does. But you should be developing practices where you can back up & start again with lessening pain. As an anecdote, I have spent weekends where I have done nothing but reinstall again & again, but usually this has been to tweak install.site scripts which addresses both partition sizes & disaster plans.

As a final comment & suggestion, if you don't like the idea of simply creating one huge partition, another alternative is to not allocate all space -- especially is the drive is large in size. As denta is suggesting, leaving free space available gives you the ability to add partitions later. If all the space on a drive is allocated, there is no room for growth.

I have no idea how big this hard drive is, but allocating 19GB to a partition for /tmp seems inordinately large

It's a 500g disk. I thought it a good idea to allocate a large space for /tmp in case I wanted to build/compile big packages or burn big iso projects .. I also saw almost the same size with the suggested autoallocation.

I'll stand by my earlier statement. You are asking the
wrong question. Ask, instead, what knowledge and skill sets you will need in order to reconfigure your partitions without reinstalling. I recommend attempting it, because you may learn something.

Friend daemonfowl, you often ask wonderful, insightful questions, but then you drop the discussion and do not seem interested in pursuing the details.

Since you haven't asked, I don't expect you to. So, rather than going through the cycle again on yet another general question, I imagined what it might be like if you had actually asked, this time.

.................................................

Quote:

Originally Posted by Rod Serling

There is a fifth dimension beyond that which is known to man. It is a dimension as vast as space and as timeless as infinity. It is the middle ground between light and shadow, between science and superstition, and it lies between the pit of man's fears and the summit of his knowledge. This is the dimension of imagination. It is an area which we call "The Twilight Zone".

Q: Is it possible to reconfigure partitions without re-installing?
A: Of course. There are special considerations for the root partition, "/", and the /usr partition. For other partitions, it's easy enough to back up, reconfigure, and restore.

Q: What procedure do you recommend for backup/restore and reconfiguration?

A: I prefer dump(8) and restore(8) to other backup/restore tools with FFS partitions, because there are no restrictions on file types or file name lengths as can happen with tar(1), cpio(1), and tools like pax(1) which use them. There are backup and restore tools in the ports tree, but they require a re-installed, fully functional system to restore to, and I prefer the simplicity of being able to use a tool in the RAMDISK kernel for bare-metal restores. The restore(8) program is included in the RAMDISK kernel though I do need to mount a small /tmp in order to use it. As for reconfiguration, I just use disklabel(8). On a few rare occasions I've been able to take advantage of growfs(8) to increase the size of an FFS partition.

Q: I've never used dump, it looks pretty complicated from the man page.

A: It can be a little complex, because it is so versatile. There are examples of the dump and restore commands when used with tape in FAQ 14.10. I've only used these tools when dumping directly to disk or being piped to other tools -- gzip(1) for compression, ssh(1) or nc(1) for network dumps, or some combination. I often use dump/restore piped together when replicating directories or filesystems. For example, "cd /new/location; dump -0af - /old/location | restore -rf -" will replicate the files hierarchy /old/location to /new/location. The "-" file is standard output for dump, and standard input for restore.

Q: Tell me about the partitions with special considerations?

A: The /usr partition contains applications and libraries -- /usr/bin and /usr/lib. Your /usr/local hierarchy might be in its own filesystem, but it too has the same considerations. You don't want to be dependent on anything in those directories while you are moving them, which might include times when they are not available. You are limited, therefore, to using tools within the root filesystem: /bin, /sbin. You need to boot into single user mode, so that no applications dependent on /usr (or /usr/local) are running. How you get there varies by architecture (e.g.: "-s" at the boot> prompt for i386 and amd64). You can also signal init(8) to enter single user mode. Manipulating the root filesystem is more complicated still.

Q: What would I need to do for the root filesystem?

A: You would need to use the shell from the RAMDISK kernel, as the root directory must be unmounted to be manipulated. The tools there are fewer -- growfs isn't included in the RAMDISK image. But newfs(8) and restore(8) are, though as I mentioned above, you'll need to mount a partition to be used as /tmp to use restore(8). In addition, you will need to reinstall boot blocks, and that too will vary depending upon the architecture. The i386, amd64, and sparc architectures (at least) have an installboot(8) program.

Q: Any recommendations before I begin?

A: Yes. Back up your system before beginning. Really. Even if you have sufficient disk space on your currently attached drive(s) to move things around, it's easy to make a mistake. If you don't have a backup, you won't have anything to restore.

.................................................

Thank you for tuning in for this week's episode of ... The Twilight Zone.

Last edited by jggimi; 4th May 2012 at 05:46 PM.
Reason: 1 typo, some clarity

@jgimmi ,thank you very much !! I was about to ask the *right question* but found your anticipated *Tasogare* Post .. :-)

Quote:

you often ask wonderful, insightful questions

prithee, don't kill me with laughing .. :-)))

Quote:

but then you drop the discussion and do not seem interested in pursuing the details.

Definitely not because disinterested .. I'd fail somewhere in the middle .. and got clueless what/how to ask a relevant question then.I've noticed that a few problems I faced were solved via other members raising them properly .. those were knowledgeable enough to ask right.

Quote:

Thank you for tuning in for this week's episode of ... The Twilight Zone.

lol .. I would believe a newb's eccentricity may remind of some TZ protagonist .. we can't escape being part of Serling's character World in one way or another.

You unlock this door with the key of imagination. Beyond it is another dimension: a dimension of sound, a dimension of sight, a dimension of mind. You're moving into a land of both shadow and substance, of things and ideas. You've just crossed over into... the Twilight Zone.

In today's episode, I have imagined what it might have been like if you had begun playing with backup(8), restore(8), and the bsd.rd RAMDISK kernel and then found you had some specific questions.

Q: I've been practicing backups and I'm confused by the "dump levels". I know level 0 is a full backup but I do not understand the various other levels.

A: Only in combination with data stored in /etc/dumpdates from prior dumps (enabled with -u) will non-zero dump levels have any meaning. Simple example: Monthly level 0 full backups, weekly level 1 backup, daily level 2 backups. This is shown in the "1 2 2 2..." example in the dump(8) man page. The other examples in the man page show some other alternatives, and you can design a backup scenario to fit your own needs. Just make sure -u is included in your dump commands in your backup script.

Q: I've been playing with backup via nc(1) and ssh(1). Both options are working really well. However, I have been testing "bare metal" restores with qemu and I've discovered that neither network tool are available on the bsd.rd RAMDISK kernel. How are you able to restore over a network onto bare metal?

A: The RAMDISK kernel environment includes ftp(1). It can pipe output (via -o -) and supports FTP, HTTP, and even HTTPS if necessary. It's not easy to deploy client certificates for HTTPS, so if you need it to transit an insecure network I recommend restricting access to the HTTPS server by IP address.

Q: I also discovered why I need to mount /tmp disk to the RAMDISK kernel -- there's not enough free space on the ram disk for any temporary files used by restore(8). However my disk I'm restoring to is fully allocated. What do you do in this situation?

A: Your "b" partition is swap space, isn't it? If so, just format it with newfs(8) and mount it as /tmp.

Q: Cool! Wait..... Where do I find my disklabel if I didn't print it out on paper or write it all down, in advance? I don't have a "b" partition if the disk drive is empty.

A: You can restore your disklabels from a backup of the filesystem containing /var/backups -- a copy will be placed there by security(8) whenever one is not there or it notes a change.

On MBR architectures, start with fdisk(8) so that the disk can be made bootable. # fdisk -iy <drive> will create a default MBR with a single OpenBSD MBR partition for the entire drive.

Use disklabel(8) to create a partition. Format it with newfs(8). Then use mount(8) to mount it as /tmp. # cd /tmp and then restore(8) your /var/backups there.

Copy the disklabel file from /tmp into / so that you can dismount /tmp. You'll need to do that in order to use disklabel(8) to restore the disklabel from the file. There is very very little free space on the ramdisk kernel, but there should be enough to copy the disklabel prototype file there. If not, write down the partitions by hand.

Q: Um, what about my laptop? It doesn't run security(8) very often, because it is suspended or powered off over night.

A: Start daily(8) and weekly(8) manually on systems which are not normally powered on when not in use, or alter the schedule in root's crontab(1 and 5).

Q: Do you have a recommended schedule for backups?

A: That will depend entirely on your needs, which are unique to you and your systems. For convenience, you could start your backup script(s) from daily.local(5), weekly.local(5), monthly.local(5) if you have daily/weekly/montly backups. If you need other times of day or different schedules, just start your script(s) from within root's crontab(1 and 5).

Quoting shakespeare :
@ jgimmi .. a worthy gentlemen ... as bountiful as mines of India
so is @ocicat .. thank you gentlemen !!
Accept this please , hoping you like New Age Piano , thanksgiving by George Winston :http://www.youtube.com/watch?v=LA05a...eature=related

Interesting hint :

Quote:

Q: Um, what about my laptop? It doesn't run security(8) very often, because it is suspended or powered off over night.

A: Start daily(8) and weekly(8) manually on systems which are not normally powered on when not in use, or alter the schedule in root's crontab(1 and 5)