View previous topic :: View next topic |
Author |
Message |
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Tue Jan 15, 2008 9:58 pm Post subject: [TRICKS] Speed up system with aufs + squashfs |
|
|
Introduction:
Hello guys, here's a thing I've been working on lately, trying to speed up my gentoo system and free some hard drive space in the process. It all starts from the observation that these days the hard disk is the choke point of the operating system in most cases; you spend a lot of time waiting for applications to load their data from the disk, while the processor rarely reaches 100% usage (my laptop's Turion 2GH cpu usually sits at 800mhz, since I'm using the ondemand cpu freq governor). So wouldn't it be nice if you could transfer some of the effort that the disk spends reading data to the processor? Actually, there is a way to do this, it's been around for a long time, you can compress the data on the disk, so that you load less data and spend a bit of extra time uncompressing it. Most applications, though, don't keep their data in compressed format, so we need to help them a bit. In this article I will tell you how you can improve data loading speed and free some disk space in the process, by using the aufs and squashfs file systems.
Warning: if you don't feel comfortable with recompiling your kernel, editing startup scripts, and generally handling by yourself different problems that you bump into, you'd better skip this one, as it requires a lot of manual work to get going, and I am sure that a lot of things _could_ go wrong, depending on your system and the way you do the procedure I am just about to describe. I won't be held responsible for any losses that you might have because you 'just thought to try this', without fully understanding what is happening and how to cope with problems that might appear.
What you need to do:
Step 1: Recompile your kernel with squashfs support. You can get it from http://squashfs.sourceforge.net/ . I recommend you compile the module into the kernel, as it will be needed from the very start of the boot process anyway...
[EDIT:] As of gentoo-sources-2.6.24 , squashfs is in the kernel already, so nothing to do at this step, if you have an up-to-date kernel
Step 2: Download and install aufs from http://aufs.sourceforge.net/ . You will need to make and install it. Be sure to read how to use it, because you will mount it a bit differently compared to your other file systems. If you ever used unionfs, you know what I mean. After installing it, add it to /etc/modules.autoload.d/kernel-2.6 .
Step 3: Restart your system with the new kernel and play around a bit with aufs and squashfs, to be sure you understand how they work. It's better to do it now, when it is safe, to avoid having difficulties later on
Step 4: Move your portage distfiles folder outside of /usr . We are going to compress the /usr folder into a squashfs image, there's no use in adding a whole bunch of archives to this image, it will just add a lot of time to the compression process... Just move /usr/portage/distfiles to a different location and add the line DISTDIR="<new_folder>" to make.conf
Step 5: Create the following folders (just a suggestion, you can choose different names/locations, after you understand the process):
Code: | /squashed/usr
/squashed/usr/ro
/squashed/usr/rw |
Step 6: Compress the /usr folder into a squashed image in /squashed/usr. Just run Code: | mksquashfs /usr /squashed/usr/usr.sfs -b 65536 |
to do this. Note that you can play around with the block size for the squash file system, I didn't run enough tests to be sure that 64k is best for all cases, but I think it is a good enough value to start with.
Step 7: Add the following lines to /etc/fstab:
Code: | /squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0 |
Step 8: Open /sbin/rc and look for the call to halt.sh. I should be in the part where the reboot and shutdown softlevels are processed. Add the following lines just BEFORE the 'LC_ALL=C exec /etc/init.d/halt.sh "${SOFTLEVEL}"' line:
Code: | einfo "Unmounting stubborn squashfs folders"
umount -l /usr
umount -l /squashed/usr/ro |
[EDIT:] I guess that steps 7&8 could be implemented as a boot script...
Step 9: Reboot and test that your system still works as expected. You should notice a speed improvement (even though at the moment you are using more disk space).
Step 10: unmount /usr (the aufs mount), rm -rf /usr/* (remove all the initial /usr folder contents!!! Might want to make a backup instead, to be sure nothing bad happens here). Then, re-mount /usr.
Step 11: You are done, enjoy!
Step 12: Once in a while (every couple of weeks, or whenever you think /squashed/usr/rw is already taking too much space), re-make the usr.sfs image. Do something like this:
Code: | mksquashfs /usr /squashed/usr/usr_tmp.sfs -b 65536
umount -l /usr
umount -l /squashed/usr/ro
rm /squashed/usr/usr.sfs
mv /squashed/usr/usr_temp.sfs /squashed/usr/usr.sfs
rm -rf /squashed/usr/rw/*
mount /squashed/usr/ro
mount /usr |
You can/should compress other folders this way. My suggestion is that you at least also compress /opt and /lib, but you could also compress /bin and /sbin. WARNING: DON'T delete the original folder contents of the /lib folder after compressing it. Its contents are needed by the mount.aufs utility itself. If you delete it, you will get a broken system and will need a LIVECD to repair things. Just mount the aufs /lib over the initial /lib folder. You will waste a bit of disk space this way, but you will still get the speed increase, and you are going to be safer. As a matter of fact, any folder that is small enough to begin with (/bin /sbin /lib ) should be treated the same. Don't bother compressing folders that contain non-compressible data, or that change often (/home, /root, /var). Also, for folders that contain a lot of smaller files, you can think about decreasing the squashfs block size to 32k, or 16k, because otherwise you might lose on the speed improvement. Feel free to test different scenarios.
Note: As you have probably already understood, the write speeds are not affected, since all writes are done onto the base file system, in /squashed/usr/rw. Files that get written to once will be read from the rw folder afterwards, therefore losing any speed benefit. That's why it makes no sense to apply this procedure to folders that change frequently.
Benchmark results:
I have compressed /bin /sbin /lib /opt /usr and then tried the following operations with and without the squashfs images mounted:
1) start the system up to the login screen
2) login and wait until desktop is usable (session is restored, hard disk stops screaming)
3) start openoffice-writer
4) start eclipse
5) generate random file access pattern and record the total time to read all files.
Code: | # find /usr -type f -printf "%s %p\n" | sort -R | awk '{ printf $2; printf "\n" }' > /sort
# time cpio -o --quiet -H newc < sort > /dev/null |
Times without squashfs+aufs:
1) 7.5 seconds to load the kernel, another 10 seconds until file systems are mounted (up to this point no speed increase is possible by this method), another 42 seconds until the login screen pops up (out of which 24 seconds are just for waiting on the network interfaces). A total of 60 seconds, out of which only 18s are relevant to our benchmark
2) 16s
3) 9s
4) 25s
5) 36m31.726s
Times with squashfs+aufs:
1) total time: 58s, out of which 16s are relevant to the benchmark -> 11% decrease in time
2) 10s -> 37.5% decrease
3) 6s -> 33% decrease
4) 22s -> 12% decrease
5) 9m48.873s -> less than 1/3 of the normal time!
Also, the /usr folder only takes 1.1Gb on my disk, compared to 3.1Gb it had before; the /opt folder takes 221mb, instead of 544mb, the others take a bit more right now, since i haven't deleted the original files, just mounted over them (12mb more... barely noticeable).
Note: I'm open to suggestions about other benchmark procedures to use here... Please keep in mind that I need something that will check the read performance for files that already exist on the disk, otherwise it's useless (bonnie++ can't be used, as far as I can tell)
Node: I have 1 GB of RAM, which, as far as I know (I don't pretend to be a linux guru), is being used by the OS to do disk caching as much as possible. And yes, the OS would be caching the compressed sectors (not the uncompressed data) from the squash file every time you try to read something from /usr. Considering that the compress ratio for /usr is almost 3x, you suddenly have 3 times more disk cache than before, without investing in extra RAM chips . If you have something like 2gb ram, you will probably never need to load the same data from /usr twice during a session, as your compressed /usr probably fits entirely into your free ram. You can imagine how fast a simple decompress from memory is, compared to a read from the hard-drive.
NOTE: If you are using squashfs 3.3 (and you probably are at the time I wrote this guide), use the -no-sparse argument when calling mksquashfs. I've had problems with corrupted files without this option, and Phillip Lougher (creator of squashfs) said this is due to a bug in the current release. It would have been a nice option, but not one that will make too much of a difference, anyway... Read the change log for future versions of Squashfs to see when this bug gets fixed.
Credits:
I initially got the idea by reading https://forums.gentoo.org/viewtopic-t-465367-highlight-aufs.html (synss is explaining how to compress the portage folder to save a lot of disk space and to increase the portage syncs speed)
Lots of thanks to Phillip Lougher, the creator of squashfs, for giving me the chance to implement something like this and for providing me with answers to some squashfs problems that I had.
Comments and more test results from your machine are very much welcome.
Note: you can read more about how much better squashfs is compared to other filesystems (including ext3) here: http://elinux.org/Squash_Fs_Comparisons
Last edited by stanbogdan on Wed Feb 06, 2008 9:00 am; edited 8 times in total |
|
Back to top |
|
|
Bones McCracker Veteran
Joined: 14 Mar 2006 Posts: 1611 Location: U.S.A.
|
Posted: Wed Jan 16, 2008 9:41 am Post subject: |
|
|
Seems like a good idea for a system that's relatively static (like embedded or firewall/router). |
|
Back to top |
|
|
pussi l33t
Joined: 08 May 2004 Posts: 727 Location: Finland
|
Posted: Wed Jan 16, 2008 5:05 pm Post subject: |
|
|
Thanks for the tip.
I think I'm going to try this :) |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Wed Jan 16, 2008 10:18 pm Post subject: |
|
|
I suggest that if you just want to give it a try, then create a squash image of the /lib32 (or /lib64 , if you have a 64-bit processor) and mount it using squashfs + aufs over the initial /lib folder. Don't delete anything, it would be unsafe, and expect the system to hang at the end of the shutdown process, because someone is bound to still have files opened from /lib (and therefore, the aufs daemon will refuse to unmount it). You can either just wait at that moment, it will eventually shutdown, after a number of retries, or you can edit the shutdown part from /sbin/rc to call a lazy unmount for the aufs and the squashfs mounts -> that will take care of any problems.
After doing this, you can run benchmarks with and without this setup, see if it helps even a little bit. Please post back any results you get |
|
Back to top |
|
|
pussi l33t
Joined: 08 May 2004 Posts: 727 Location: Finland
|
Posted: Thu Jan 17, 2008 4:38 pm Post subject: |
|
|
why /lib? wouldn't /usr be safer and more effective? |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Thu Jan 17, 2008 7:57 pm Post subject: |
|
|
Well, for /lib I was suggesting that you only make a squashed image and mount it over the original /lib folder, without deleting it first, so as far as safety goes, you don't have to worry about anything, if the mount fails, the original data is still there. Squashing /usr will take a lot longer (it has 8.5 gb on my machine, that takes a while to compress...), and in order to keep it safe for the initial tests, you would also have to keep the original folder, therefore spending a lot of your hard drive space until you finally decide it is safe to delete it entirely (well, almost entirely, as I said, some things from /usr/bin would have to be kept in order to allow the mount.aufs script to run). If you have the hard drive space and time to also compress /usr, feel free to do that also, it should definitely add to the performance.
P.S. if you want to make extensive tests and play a lot with different possibilities, I suggest you keep a LiveCD handy, just in case something goes wrong... |
|
Back to top |
|
|
pussi l33t
Joined: 08 May 2004 Posts: 727 Location: Finland
|
Posted: Thu Jan 17, 2008 8:17 pm Post subject: |
|
|
ah.. good point. I was going to mount the squashfs over the orginal anyway just in case. My /usr is only 2.6G though so I might just go with it. |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Wed Jan 30, 2008 12:56 pm Post subject: |
|
|
Just updated the initial post with more detailed information and some other benchmark results. |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Sun Feb 03, 2008 8:12 pm Post subject: |
|
|
And yet even more benchmark results added to the initial post (the random access pattern part) |
|
Back to top |
|
|
waynesherman n00b
Joined: 08 Feb 2008 Posts: 1
|
Posted: Fri Feb 08, 2008 2:59 am Post subject: |
|
|
First of all, Stan, thanks for your work on this tip.
I ran across a problem not documented here. When I tried to reboot after deleting the contents of my /usr directory, I ended up with lots of error messages. It turns out that my aufs mount failed and /usr was empty. Looking back at the log revealed why:
1) The aufs mount in /etc/fstab depends on mount.aufs
2) mount.aufs is a shell script which happens to depend on 4 files in /usr/bin:
Code: | /usr/bin/comm
/usr/bin/diff
/usr/bin/paste
/usr/bin/tee
|
3) Since the /usr directory was empty at that point in the boot process, mount.aufs failed.
The solution to fix the immediate problem is to create a /usr/bin directory and copy those files to it (or when you delete everything in /usr, don't delete the /bin directory and those 4 files). That way when mount.aufs executes, it can find the 4 files. aufs will then mount the unioned /usr on top of the existing /usr which in effect hides those files.
A problem remains: I don't know how those files are going to receive updates. Any ideas?
Has anyone else seen this behavior?
If yes, how did you fix it?
If no, why does it happen on my system and not others?
Thanks,
Wayne |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Fri Feb 08, 2008 5:04 am Post subject: |
|
|
waynesherman wrote: | First of all, Stan, thanks for your work on this tip.
I ran across a problem not documented here. When I tried to reboot after deleting the contents of my /usr directory, I ended up with lots of error messages. It turns out that my aufs mount failed and /usr was empty. Looking back at the log revealed why:
1) The aufs mount in /etc/fstab depends on mount.aufs
2) mount.aufs is a shell script which happens to depend on 4 files in /usr/bin:
Code: | /usr/bin/comm
/usr/bin/diff
/usr/bin/paste
/usr/bin/tee
|
3) Since the /usr directory was empty at that point in the boot process, mount.aufs failed.
The solution to fix the immediate problem is to create a /usr/bin directory and copy those files to it (or when you delete everything in /usr, don't delete the /bin directory and those 4 files). That way when mount.aufs executes, it can find the 4 files. aufs will then mount the unioned /usr on top of the existing /usr which in effect hides those files.
A problem remains: I don't know how those files are going to receive updates. Any ideas?
Has anyone else seen this behavior?
If yes, how did you fix it?
If no, why does it happen on my system and not others?
Thanks,
Wayne |
I have noticed the same problem the first time I tried this trick, and the solution was, as you have tried, to keep all the files needed from /usr/bin. I guess that you could just keep a complete stage3 /usr, to allow not only for mount.aufs to work, but to also have a working system if you run into any problems (vim, gcc, emerge, etc), without needing a LiveCD nearby. I will need to further investigate this matter at some point, right now I am trying to make up some scripts to make things easier for anyone. Until then, if you don't really have hard drive space issues, you can keep your /usr folder untouched and just mount the squashfs+aufs folder on top of it, getting the speed benefit, but losing some space on the drive.
About your question on how the files you mentioned are going to receive updates... I guess they won't, under these circumstances, not unless you update them manually from time to time (unmount /usr, copy those files from /squashed/usr/ro/bin to usr/bin, remount /usr). But then again, they shouldn't need an update at all, not unless they depend on some library that becomes obsolete and gets deleted from the file system (but, then again, you are keeping your unsquashed /lib folder untouched, right?) |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Fri Feb 08, 2008 5:10 am Post subject: |
|
|
UPDATE: If you happen to have (or are able to buy) a fast and big enough usb stick (I got my hands on a Corsair Voyager GT, 20MBps sustained read speed), you can copy the squashed image on it and mount it from there. Not only does the usb stick have a MUCH faster random access speed (2 or 3 times faster, on average, due to the fact that it has no moving parts), but it can be accessed in parallel to your hard drive, therefore taking even more pressure off it. If you want to do this, you should really keep your unsquashed /usr folder untouched on the main drive, you don't want to be unable to use your computer just because you don't have the usb stick nearby... |
|
Back to top |
|
|
Bumbl n00b
Joined: 05 Sep 2007 Posts: 50
|
Posted: Sun Feb 10, 2008 5:06 pm Post subject: |
|
|
stanbogdan wrote: | UPDATE: If you happen to have (or are able to buy) a fast and big enough usb stick (I got my hands on a Corsair Voyager GT, 20MBps sustained read speed), you can copy the squashed image on it and mount it from there. Not only does the usb stick have a MUCH faster random access speed (2 or 3 times faster, on average, due to the fact that it has no moving parts), but it can be accessed in parallel to your hard drive, therefore taking even more pressure off it. If you want to do this, you should really keep your unsquashed /usr folder untouched on the main drive, you don't want to be unable to use your computer just because you don't have the usb stick nearby... |
this would be something like vistas readyboost technologie, wouldn't it?
would you possibly be so kind as to do another benchmark run with the usb-stick because i'm playing with the idea of buying me one of the 16gb crosair sticks, because: you could never have a fast enough system, i like the idea, it would be cool and it would be something to play with (which is why i use gentoo) |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Sun Feb 10, 2008 7:02 pm Post subject: |
|
|
Bumbl wrote: | stanbogdan wrote: | UPDATE: If you happen to have (or are able to buy) a fast and big enough usb stick (I got my hands on a Corsair Voyager GT, 20MBps sustained read speed), you can copy the squashed image on it and mount it from there. Not only does the usb stick have a MUCH faster random access speed (2 or 3 times faster, on average, due to the fact that it has no moving parts), but it can be accessed in parallel to your hard drive, therefore taking even more pressure off it. If you want to do this, you should really keep your unsquashed /usr folder untouched on the main drive, you don't want to be unable to use your computer just because you don't have the usb stick nearby... |
this would be something like vistas readyboost technologie, wouldn't it? |
Yep, it would be similar to Vista's readyboost, just that instead of caching only the files that prove to be frequently accessed, it caches the files that YOU want to be cached, preferably all of them (if you have a big enough usb stick). Also, the fact that the data is compressed allows you store more data, and (I suspect, might be different for the usb stick), read it faster.
Bumbl wrote: | would you possibly be so kind as to do another benchmark run with the usb-stick because i'm playing with the idea of buying me one of the 16gb crosair sticks, because: you could never have a fast enough system, i like the idea, it would be cool and it would be something to play with (which is why i use gentoo) |
Preliminary tests show that it is a LOT faster than reading from the hard drive, at least for random reads. I created a random access pattern for 20% of all files from my /usr folder, and tried to read all of them with the squash image on the drive, then with the squashed image on the stick. The stick-mounted image was two times faster... I have changed a lot of things on my drive since the previous benchmarks, so I will just run all the tests mentioned in the main post again, in all 3 cases: with no squashed image, with a hard-drive squashed image, and with a flash stick image. I'm also done with writing a script that will allow for a much better management of squashed images. Expect a new post tomorrow, after I am able to run a couple of more organized tests. |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Mon Feb 11, 2008 8:23 am Post subject: |
|
|
New benchmark results, after testing out the Corsair Voyager GT flash stick. The list of tests that were run is:
1) Start the computer and time how long it takes after you enter your password in the login screen, until the desktop is fully usable (hard disk lights stop blinking)
2) Start a lot of programs, save the session, reboot and time how much it takes to go from the login screen to the moment when the entire session is completely restored (same as 1, but with a bigger session to restore)
3) Test sequential read speed for a part of the file system: Code: | #time tar cf /var/tmp/portage/tmp /usr/lib64 |
Note: /var/tmp/portage is mounted in RAM as a tmpfs mount (did it to increase emerge speeds)
4) Test random access speed for a part of the file system: Code: | # find /usr -type f -printf "%s %p\n" | sort -R | awk '{ printf $2; printf "\n" }' > /sort
# delete last 80% lines from /sort
# time cpio -o --quiet -H newc < /sort > /dev/null |
Note: I deleted 80% of the sort file because the entire squashed file fits into my RAM, therefore, once a sector from the squashed file system is loaded into memory, it would never be flushed out during the test. Any subsequent reads of files from that sector would be very quick and would not be dependent on the file system or its support (stick / hard-disk)
5) Same test as the one at point 4, but with a reasonably high stress on the cpu (4 consoles doing cat /dev/urandom > /dev/null). The cpio process was unable to get more than 20% of the CPU, as checked with top
Result set 1: no squashed image
1) 6.5s
2) 29s
3) 130s
4) 608s
5) 596s
Result set 2: squashed image on hard-disk
1) 4s
2) 23s
3) 41s
4) 193s
5) 232s
Result set 3: squashed image on usb flash stick
1) 3.5s
2) 20s
3) 32s
4) 74s
5) 228s
Conclusions:
1) Using a squashed image of your /usr folder visibly increases overall performance of your system, as far as disk loading times are concerned
2) Using a high-speed USB stick as a support for the squashed image further increases access speeds, especially when doing sustained random reads from the disk.
3) Having a high cpu-load while trying to access the disk has no effect in the normal case, but the squash image performance is seriously affected, because it needs cpu time to uncompress the data loaded from the disk. The performance still does not decrease anywhere near the normal performance (with no squashed image), and you would normally expect an application to first load its data, and only then process it. Still, this means that while reading a lot of data from your squashed /usr folder, you might notice a system-wide slowdown. Not that you wouldn't also see that in the normal case, with the hard-disk screaming like it's about to break down while trying to access hundreds of files per second...
P.S. As I said in my previous post, I have simplified the process of making the squash file, mounting it from different locations, etc. I need to brush up on the script, though, at the moment I still have problems from time to time, having to shut down using the power button... I'll update the main post when I'm done with it, at which point I will also include these last benchmarks in it. |
|
Back to top |
|
|
grayskunk n00b
Joined: 31 Oct 2004 Posts: 24
|
Posted: Mon Feb 11, 2008 5:03 pm Post subject: |
|
|
I have a file server with many compressed, read-only .tar.gz files. Would a squashfs decrease the size of compressed files to where it is worth doing? |
|
Back to top |
|
|
stanbogdan n00b
Joined: 14 Jan 2008 Posts: 12
|
Posted: Mon Feb 11, 2008 7:17 pm Post subject: |
|
|
I doubt that squashfs would be able to compress your files into a smaller size than your current situation... It uses the same compression algorithm (GZIP), but only compresses each sector separately (4k - 1mb at a time, depending on what you choose when creating the squashed file). Also, you would have to keep your data in uncompressed format in your squashfs file system (they would be compressed by squashfs itself, but from the outside they will seem to be uncompressed), which, I guess, is not what you want for a file server. Anyway if you are looking for a way to optimize access to your .tar.gz files, and/or decrease the amount of space they occupy on the drive, using a squashfs image is not going to help, or is not going to help enough to be worth the effort.
You might have better luck just compressing your /usr folder, that could save some useful space that you can use to store more files on your server, though... |
|
Back to top |
|
|
grayskunk n00b
Joined: 31 Oct 2004 Posts: 24
|
Posted: Mon Feb 11, 2008 7:36 pm Post subject: |
|
|
thanks for the I will try out your tip on my /usr folder. Thannks! |
|
Back to top |
|
|
Phoenix591 Guru
Joined: 17 Sep 2007 Posts: 492
|
Posted: Tue Feb 12, 2008 12:15 am Post subject: |
|
|
would anyone be interested in a bash script that automaticly copies your current kernel configuration (stored in a seperate file) to your new kernel (presymlinked to /usr/src/linux) and patches it for aufs, and builds it? its (pretty) well commented. and Works for Me (tm) |
|
Back to top |
|
|
drescherjm Advocate
Joined: 05 Jun 2004 Posts: 2790 Location: Pittsburgh, PA, USA
|
|
Back to top |
|
|
Phoenix591 Guru
Joined: 17 Sep 2007 Posts: 492
|
Posted: Thu Feb 14, 2008 4:47 pm Post subject: |
|
|
well, it still was a good chance to improve my bash , and it just simply improved my existing script |
|
Back to top |
|
|
drescherjm Advocate
Joined: 05 Jun 2004 Posts: 2790 Location: Pittsburgh, PA, USA
|
|
Back to top |
|
|
Phoenix591 Guru
Joined: 17 Sep 2007 Posts: 492
|
Posted: Sat Feb 23, 2008 12:42 am Post subject: |
|
|
lost it . I foolishly just copy and pasted the posts instructions to update /usr . there was a typo. lost everything relitivly recent in my /usr. |
|
Back to top |
|
|
drescherjm Advocate
Joined: 05 Jun 2004 Posts: 2790 Location: Pittsburgh, PA, USA
|
|
Back to top |
|
|
SlashBeast Retired Dev
Joined: 23 May 2006 Posts: 2922
|
Posted: Sun Mar 16, 2008 12:40 pm Post subject: |
|
|
Work for me, THX! .
Imho good idea is mv /usr/src to (for example) /squash/non-squashed/src and link /usr/src to /squash/non-squashed/src.
Without src and distfiles
Code: | jinchuuriki slashbeast # du -sh /usr
3,1G /usr
jinchuuriki slashbeast # du -sh /squash/squashed/usr.sfs
1,4G /squash/squashed/usr.sfs |
Faster, smaller, squashy rox. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|