Page 1 of 2

transfer /tmp to system memory.. good idea?

Posted: Mon Jan 21, 2019 9:53 pm
by redlined
Looking for solutions to an applet issue in forum I reread something offsite that finally stood out, and with 8GB system ram I feel I can space 500MB easy enough. I've only hit swap a couple times, when running handbrake and VM mostly, and compiling when I try that.

anyway, the below is quote from author of VPN LookOut, a fave of mine:
https://cinnamon-spices.linuxmint.com/applets/view/305
Transfere the /tmp directory into memory (Useless for Arch)

It is recommended to transfere the /tmp directory into memory, for two reasons:

Make applet execution faster.
Reduce hard disk wear (especially if it's a SSD).

To do this, add this line at the end of the file /etc/fstab; then, restart the computer:
tmpfs /tmp tmpfs defaults,size=500M 0 0 (Beware to put the final character 's' at the 'defaults' word. In the size parameter, 'M' is for MB, 'G' is for GB; be careful, the memory allocated for /tmp is no longer available for the rest.)
sounds like a very good idea faster apps and: "especially if it's a SSD"

thoughts?

Re: transfer /tmp to system memory.. good idea?

Posted: Mon Jan 21, 2019 10:22 pm
by WharfRat
With systemd copy /usr/share/systemd/tmp.mount to /etc/systemd/system/ instead of an fstab entry then issue sudo systemctl enable tmp.mount

I've been using it for years,

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 3:10 pm
by redlined
WharfRat wrote: Mon Jan 21, 2019 10:22 pm With systemd copy /usr/share/systemd/tmp.mount to /etc/systemd/system/ instead of an fstab entry then issue sudo systemctl enable tmp.mount

I've been using it for years,
fascinating, I think want to try this! :mrgreen:

is /systemd/tmp.mount a RAM drive sort of effect? if so, how do I set the amount of RAM to dedicate to this? I see inside the file reference to man hier but that isn't telling me much

and... I'm lost at: "With systemd copy" :?
is this to say have systemd do it for me and to do so
sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/tmp.mount
then run manual or make cron job or script on startup to run sudo systemctl enable tmp.mount :idea:

edit to change cp -r command to mv in my semiwildazzguess example (swag :oops:
...and edit again to change mv back to cp.

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 3:42 pm
by WharfRat
Don't mv the file, cp the file from /usr/share/systemd/tmp.mount to /etc/systemd/system,

The initial sudo systemctl enable tmp.mount will mount it immediately.

Systemd will mount /tmp to tmpfs at boot time.

tmpfs. From Wikipedia, the free encyclopedia. tmpfs is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but stored in volatile memory instead of a persistent storage device.

It's best to let systemd temp mount to handle the amount of memory, but if you insist https://unix.stackexchange.com/question ... e-manually

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 4:02 pm
by rene
/tmp on tmpfs has been the default for many years on e.g. Red Hat and Arch and it was one of the first things I adjusted when I entered the Debian universe in the form of Mint 17 and noted it not doing so. Then somewhat later, I unadjusted again and have semi-recently revisited the decision upon rolling out more SSDs in the sense of feeling it potentially useful to limit writes.

Although there's arguments for both I personally use standard, disk based /tmp. Admittedly, that is partially due to me through having used a fair number of different distributions having for some time found it preferred to just go with rather than battle distribution defaults, but I've also mostly convinced myself that I do in fact want disk based /tmp.

The system I'm typing this on has been running all day now:

Code: Select all

rene@t5500:~$ sudo du -sh /tmp
92K	/tmp
I can guarantee you that the entirety of that 92K is cached somewhere in the 12 * 1024 * 1024K of RAM on this machine; that it is already in RAM, and that as such at least speed is not an issue. If I were moreover worried about writes there's quite a few better things to look at such as the browser cache in my home directory. Yet, I most certainly do keep that on SSD, not having bought the blasted things for nothing...

And then, occasionally, you do in fact run into a situation where you need serious space on /tmp; when I was the other day experimenting with Brasero's CD-DA ripping due to a post on this forum I for example noticed it using /tmp as an intermediate store. I suppose it will or at least can do the same for image burns. One other I remember from a while ago is TexMaker saving default project files to /tmp and expecting them to survive a reboot. Now, that's a wrong assumption also with disk based /tmp but the fact of the matter is that it used that mechanism for years on the by its customers by far most used Ubuntu and other Debian (-based) systems on which it did always work (I believe that these days systemd will scrub /tmp anyway, but, well).

Yes, both those examples might already be covered by my first mentioned "go with the defaults" preference, first if only due to the Debian packager hopefully configuring Brasero differently when /tmp on tmpfs would be standard, but given before mentioned minimal regular use of /tmp I've concluded that I find adjusting things myself definitely not worth the effort.

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 4:13 pm
by redlined
Thanks for clarifying and explaining the process WharfRat!

changing mv back to cp, I was confusing myself :|
Sounds dynamically sized/managed, not a static size as my initial post suggests doing via fstab edit method. I was worried to drain system of usable RAM, although 8GB is pretty good amount for even today standards.

From stackexchange link I see command df -h /tmp
which returns:

Code: Select all

~$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G   92K  3.9G   1% /tmp
which is telling me 92K is used of allocated 3.9G for tempfs, as this is before I copy tmp.mount and run sudo systemctl enable tmp.mount is that 3.9G is dynamic amount :?: or am I looking at this wrong :oops:

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 4:19 pm
by philotux

Code: Select all

sudo systemctl enable tmp.mount
Just wondered if I should run

Code: Select all

sudo systemctl start tmp.mount
as well if I am not going to reboot?

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 4:33 pm
by redlined
@rene, some more to consider before I jump in and send /tmp to tempfs!
note to self: man du && man df :mrgreen:

@philotux, good point! or maybe restart DE, or logout and back in :?:

errr, maybe not... in man systemctl:
enable NAME..., enable PATH...
Enable one or more units or unit instances. This will create a set
of symlinks, as encoded in the "[Install]" sections of the
indicated unit files. After the symlinks have been created, the
system manager configuration is reloaded (in a way equivalent to
daemon-reload), in order to ensure the changes are taken into
account immediately.
Note that this does not have the effect of
also starting any of the units being enabled. If this is desired,
combine this command with the --now switch, or invoke start with
appropriate arguments later.
I think it is telling me the /tmp into tempfs is immediate (a service), if it was a process then --now flag or start option run later will do it.

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 5:24 pm
by philotux
redlined wrote: Tue Jan 22, 2019 4:33 pm I think it is telling me the /tmp into tempfs is immediate (a service), if it was a process then --now flag or start option run later will do it.
So, will sudo systemctl enable --now tmp.mountboth enable the service and starts running it immediately? That's how I read the man page lines you quoted, I think :?

Did you, by the way, reboot or logged off and back on again after sudo systemctl enable tmp.mount ?

Doessystemctl status tmp.mountsay it is running?
Sorry, I'm not on my Mint box to run it myself to check. I am hanging around theoretically :wink:

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 6:18 pm
by redlined
philotux wrote: Tue Jan 22, 2019 5:24 pm So, will sudo systemctl enable --now tmp.mountboth enable the service and starts running it immediately? That's how I read the man page lines you quoted, I think :?

Did you, by the way, reboot or logged off and back on again after sudo systemctl enable tmp.mount ?

Doessystemctl status tmp.mountsay it is running?
Sorry, I'm not on my Mint box to run it myself to check. I am hanging around theoretically :wink:
I may be confusing it by adding that "(a service)" to the mix from my interpreting the man (better to leave the MAN alone! :lol:

I think it is as WharfRat first mentioned:
The initial sudo systemctl enable tmp.mount will mount it immediately.
what I did and have not restarted, nor logged off (I did try a new trick for reload Cinnamon though alt+f2 then type r :mrgreen:
otherwise this is it:
sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/tmp.mount
sudo systemctl enable tmp.mount
and thanks to your tip on command, I can report this:

Code: Select all

anyuser@f023:~$ systemctl status tmp.mount
● tmp.mount - Temporary Directory (/tmp)
   Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor preset: enabled)
   Active: active (mounted) since Tue 2019-01-22 10:21:08 MST; 4h 53min ago
    Where: /tmp
     What: tmpfs
     Docs: man:hier(7)
           https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/tmp.mount

Jan 22 10:21:08 f023 systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Jan 22 10:21:08 f023 systemd[1]: Mounting Temporary Directory (/tmp)...
Jan 22 10:21:08 f023 systemd[1]: Mounted Temporary Directory (/tmp).
anyuser@f023:~$ 
which, to me, looks right, i think :lol:

and from 100K earlier I am now at:

Code: Select all

anyuser@f023:~$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G  648K  3.9G   1% /tmp
anyuser@f023:~$ 
not too shabby, need to fire up the VM and run handbrake though :twisted:

Re: transfer /tmp to system memory.. good idea?

Posted: Tue Jan 22, 2019 8:08 pm
by philotux
So, mount.tmp is not to be considered like an "ordinary" service which can be enabled and started with --now or later on with start. Once /tmp gets mounted at /tmpfs, it is activated at the same time.

It would be interesting to know if there are other directories that can safely be put on /tmpfs. I understand that one should never put /var/tmp on /tmpfs since it's content must survive a reboot.

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 11:47 am
by redlined
philotux wrote: Tue Jan 22, 2019 8:08 pm So, mount.tmp is not to be considered like an "ordinary" service which can be enabled and started with --now or later on with start. Once /tmp gets mounted at /tmpfs, it is activated at the same time.

It would be interesting to know if there are other directories that can safely be put on /tmpfs. I understand that one should never put /var/tmp on /tmpfs since it's content must survive a reboot.
hi philotux!

as I understand it the file tmp.mount is a set of instruction to OS on how to create a 'virtual disk/partition' formatted as tmpfs and can be used to as mount point for anything pointed at it. and yes, once /tmp gets mounted in this tmpfs virtual partition (in RAM) it is active immediately (as systemctl reload occurs as mentioned by WharfRat and in man systemctl)

To recap what I believe is going on now is I have a dynamically managed tempfs "partition" mounted /tmp directory that may expand to use up to 3.9GB of system RAM and basically flushes clean each restart (I imagine on logoff as well :?:

I feel this is superior to the suggested method, set a static size RAM drive to mount through fstab, as it allows the system to use exactly what is needed, when its needed, instead and not a static size that dedicates a chunk of system RAM that may or may not be used in any significant amount.

Not really anything to solve here, so leaving convo open as such for others that may weigh in with other methods and ideas as philotux mused what else is safe/good idea to direct towards tempfs. (See also Arch wiki link and quote below)

For clarity I have the following questions.
Is tempfs as my results below suggest, limited to a max size of 3.9GB? found a good Arch Linux page on tempfs that confirms tempfs default size is half RAM.

still curious, What happens when system reaches that limit? DE or system crashes is the concern, especially if taxing system memory hard at the time tempfs wants to expand for /tmp storing use

some really good info on what may be good to point at tempfs, from Arch wiki linked above:
Usage
Some directories where tmpfs(5) is commonly used are /tmp, /var/lock and /var/run. Do not use it on /var/tmp, because that folder is meant for temporary files that are preserved across reboots.

Arch uses a tmpfs /run directory, with /var/run and /var/lock simply existing as symlinks for compatibility. It is also used for /tmp by the default systemd setup and does not require an entry in fstab unless a specific configuration is needed.

glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for POSIX shared memory. Mounting tmpfs at /dev/shm is handled automatically by systemd and manual configuration in fstab is not necessary.

Generally, tasks and programs that run frequent read/write operations can benefit from using a tmpfs folder. Some applications can even receive a substantial gain by offloading some (or all) of their data onto the shared memory. For example, relocating the Firefox profile into RAM shows a significant improvement in performance.

Note: The actual memory/swap consumption depends on how much is used, as tmpfs partitions do not consume any memory until it is actually needed.
my first thought here is definitely want to get Firefox using tempfs, but load (entire) profile? :shock: perhaps better to point cache at tempfs? otherwise what happens to profile changes on reboot... is profile loaded into memory for duration of session, then closing browser writes any changes back to profile on disk (in FF default location) before dumping memory effectively wiping everything stored in tempfs?

more startpage-ninja search/research needed, and all related comments for sure still welcome!

----
otherwise, happy to report, after installing some updates this morning then reboot, all looks good :mrgreen:

Code: Select all

anyuser@f023:~$ systemctl status tmp.mount
● tmp.mount - Temporary Directory (/tmp)
   Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor preset: enabled)
   Active: active (mounted) since Wed 2019-01-23 07:25:01 MST; 38min ago
    Where: /tmp
     What: tmpfs
     Docs: man:hier(7)
           https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
  Process: 616 ExecMount=/bin/mount tmpfs /tmp -t tmpfs -o mode=1777,strictatime,nosuid,nodev (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/tmp.mount

Jan 23 07:25:01 f023 systemd[1]: Mounting Temporary Directory (/tmp)...
Jan 23 07:25:01 f023 systemd[1]: Mounted Temporary Directory (/tmp).
anyuser@f023:~$ sudo du -sh /tmp
56K	/tmp
anyuser@f023:~$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G   56K  3.9G   1% /tmp
anyuser@f023:~$ 

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 12:28 pm
by philotux
Hi redlined!

Thank you so much for the nice recap/write up!

Very interesting and thought-provoking, especially the quote from the Arch Wiki and the suggestion to put some folders from the ~/.cache on /tmpfs. I just skimmed through the article there and another one (https://wiki.archlinux.org/index.php/Fi ... ile_on_RAM) more specific to putting Firefox's profile in tmpfs. And the note of caution:
Because data placed therein cannot survive a shutdown, a script responsible for syncing back to drive prior to system shutdown is necessary if persistence is desired (which is likely in the case of profile relocation). On the other hand, only relocating the cache is a quick, less inclusive solution that will slightly speed up user experience while emptying Firefox cache on every reboot.

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 1:05 pm
by redlined
excellent find philotux! definitely looking into ~/.cache for good things to include

I think a script to write back profile, minus cache, would be a great solution for getting FF taken care of 8)

my newb writing scripts spidey senses are tingling... more like cackling with glee over the mess I'm sure to create attempting :mrgreen:
(gonna need more backups :oops: :lol:

(edit to correct: strikethru above, reason- FF cache is under ~/.cache, not a part of profile load in tempfs)

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 1:47 pm
by thx-1138
...would just like to add something in reference to SSD writes and lifetime,
as i think that lots of people frequently get really over-concerned with such...sudo tune2fs -l /dev/sda2
Filesystem created: Mon Oct 24 11:08:57 2016
Last write time: Wed Jan 23 11:07:27 2019
Lifetime writes: 6434 GB
This was a brand new disk, with a fresh Linux (Mint) installation. In 27 months, there's roughly 6.5 Tb that has been written here.
27 (months) x 30 (days), 810. Let's round it up to 825 (say to count the months that have 31 days)...
to not bore you with multiplications & divisions, that's roughly 7.8GB written per day on average.

Disks theoritically are meant to survive....a truly huge number of even 100s of Tb writes. And i'm not even close above as you can see.
Sample article as well: https://www.ontrack.com/blog/2018/02/07 ... ally-last/
A typical TBW figure for a 250 GB SSD lies between 60 and 150 terabytes written.
That means: To get over a guaranteed TBW of 70, a user would have to write 190(!) GB daily over a period of one year
(In other words, to fill two thirds of the SSD with new data every day). In a consumer environment this is highly unlikely.
Ie. with the current daily usage, theoritically, the disk would crap out at worst case scenario (60 Tb), in...19 yrs from now.

That is not to suggest to anyone don't optimize it, or don't tweak it etc.
Sure, every little bit counts - and if nothing else, since there exists the ability to further tweak such, why not...
In the case of tmpfs though, i'd say it's main benefit / reason for someone to use it,
wouldn't really be to avoid having the disk dying earlier, but more likely privacy reasons,
ie. say not having sensitive browsing data written to disk etc etc...

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 3:58 pm
by redlined
thx-1138 wrote: Wed Jan 23, 2019 1:47 pm ...would just like to add something in reference to SSD writes and lifetime,
as i think that lots of people frequently get really over-concerned with such...sudo tune2fs -l /dev/sda2
Filesystem created: Mon Oct 24 11:08:57 2016
Last write time: Wed Jan 23 11:07:27 2019
Lifetime writes: 6434 GB
This was a brand new disk, with a fresh Linux (Mint) installation. In 27 months, there's roughly 6.5 Tb that has been written here.
27 (months) x 30 (days), 810. Let's round it up to 825 (say to count the months that have 31 days)...
to not bore you with multiplications & divisions, that's roughly 7.8GB written per day on average.

Disks theoritically are meant to survive....a truly huge number of even 100s of Tb writes. And i'm not even close above as you can see.
Sample article as well: https://www.ontrack.com/blog/2018/02/07 ... ally-last/
A typical TBW figure for a 250 GB SSD lies between 60 and 150 terabytes written.
That means: To get over a guaranteed TBW of 70, a user would have to write 190(!) GB daily over a period of one year
(In other words, to fill two thirds of the SSD with new data every day). In a consumer environment this is highly unlikely.
Ie. with the current daily usage, theoritically, the disk would crap out at worst case scenario (60 Tb), in...19 yrs from now.
thanks for that perspective! and command to check :mrgreen:

Code: Select all

~$ sudo tune2fs -l /dev/sda2
[sudo] password for anyuser:              
tune2fs 1.44.1 (24-Mar-2018)
Filesystem created:       Tue Nov 20 01:39:26 2018
Last write time:          Wed Jan 23 07:25:01 2019
Mount count:              56
Maximum mount count:      -1
Lifetime writes:          22 GB   [b]/ (root)[/b]

sudo tune2fs -l /dev/sda3
Lifetime writes:          1882 GB   :oops: [b]/home[/b]

sudo tune2fs -l /dev/sda4
tune2fs: Bad magic number in super-block while trying to open /dev/sda4
/dev/sda4 contains a swap file system

[b]sudo tune2fs -l /dev/sda5
and
sudo tune2fs -l /dev/sda6
both show 
Lifetime writes:          8 TB[/b]    :shock: 

sudo tune2fs -l /dev/sdb1
Filesystem created:       Mon Dec 17 11:05:53 2018
Last write time:          Wed Jan 23 07:25:03 2019
Mount count:              25
Maximum mount count:      -1
Lifetime writes:          9 GB  /mnt/storage

sudo tune2fs -l /dev/sdb2
Lifetime writes:          5520 MB  /mnt/backup (not yet used, need to split off from sda5&6 still)
certainly need to figure out what is chewing thru TBW sda5&6 since late November, amagad! it's my Evo 860, which sports: "Reliability : 1.5 Million Hours Reliability (MTBF)" and "Up to 8x higher TBW (Terabytes Written) than the 850 EVO" which boasts: "5 Years/150TBW "
thx-1138 wrote:That is not to suggest to anyone don't optimize it, or don't tweak it etc.
Sure, every little bit counts - and if nothing else, since there exists the ability to further tweak such, why not...
In the case of tmpfs though, i'd say it's main benefit / reason for someone to use it,
wouldn't really be to avoid having the disk dying earlier, but more likely privacy reasons,
ie. say not having sensitive browsing data written to disk etc etc...
I must agree, the SSD drive life is not really as great a concern for common daily user use, even small network servers, and my desire to tempfs more temp and cache type stuff is definitely driven by desire for privacy (and just get rid of junk not needed instead of persistence between reboots and laying around until it does cause trouble...

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 4:27 pm
by thx-1138
...you're probably already aware of the following, but i'll leave it here for the potential benefit of other people as well.
rene referenced it already above: "If worried about writes there's quite a few better things to look at,
such as the browser cache in my home directory."

...At least Firefox (and i assume Mozilla derivatives?) has this annoying...not-a-bug-but-a-feature,
of literally hammering the disk every 15 secs. There's also a bug report here for what it's worth it...

I still wouldn't worry that much in terms of "amount" of data that gets written,
but the concept of it constantly writing to / polling from the disk, the "frequency" of doing so if you will,
certainly doesn't seem (to me at least) to fall on the side of 'sane default' out-of-the-box...

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 8:36 pm
by redlined
Thanks thx-1138!

I wasn't aware (but am now, and set browser.sessionstore.interval from 15000 to 1800000 :oops: ... I consider self a notorious firefox multi-tabber (think: 1-2 dozen minimum most all times +6 pinned ugh) and saving session always... along with also clearing cache on close I see I am likely rapidly chewing thru writes with FF alone.. and backup plans need some refining...

Definitely an argument for putting FF profile into tempfs with a writeback to disk script on session close!

Otherwise, I don't suspect running VPN always, nor seeding torrents cause any significant writes outside logs :?:
(26GB d/l all 32&64b Mint 19.1 editions, seeded 300GB this past month so far- for the cause! :mrgreen:

but more to check on for sure. 8TB of writes since Nov 20 is surreal imho and may very well account for the high(ish) SSD and CPU temps inxi reports :evil:

anyway, thanks for mentioning it. While this SSD has "up to 8x 150TBW" (i.e. up to 1200TB) and 1.5million hours reliability (170 or so years :lol: guarantees I'm thinking I'll get 5 years out of it, regardless :roll:
wait... 8TB/60 days=.133TB=133GB daily, 1200TB = 1200000GB, 1200000/133=9022days, or 24years +/-)
ok, not sweatin it too much (unless my maths are seriously flawed :mrgreen:

What else would be great idea to keep in tempfs... seems my new question of the month :shock:

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 9:01 pm
by redlined
... actually my new question of the month is does Linux/Mint have anything like resource and process monitor like the good ole sysinternals (now windows owned) fellas created?
ref: https://www.servethehome.com/firefox-is ... to-fix-it/

Re: transfer /tmp to system memory.. good idea?

Posted: Wed Jan 23, 2019 11:26 pm
by redlined
and since the tab was open and this is the subject, a cron job/script example for putting FF profile into tempfs, writing it back to disk (save to next overwrite) and at reboot. Sounds like he recompiled binary to force tmpfs use :?: brilliant.
post from Jame5
Went ahead and rebuilt my firefox to tmpfs file.
Adding a cron for @reboot and every half hour.

Code: Select all

#Firefox to tmpfs onboot cron
@reboot /home/jsmith/scripts/firefox_tmpfs

#Firefox every half hour tmpfs to disk sync
*/30 * * * * /home/jsmith/scripts/firefox_tmpfs
in other thread, I also got reminded of some other browsers, in particular IceCat which I had long forgotten about but have downloaded and am about to take for a test drive for a week or three..
and...movie time! :mrgreen: i'm out~