VectorLinux
December 20, 2014, 12:21:01 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1] 2 3
  Print  
Author Topic: System without hard disk.  (Read 10924 times)
nightflier
Administrator
Vectorian
*****
Posts: 4038



« on: October 23, 2007, 04:49:24 pm »

I'm somewhat sensitive to noise and keep trying to quiet my workstation.

I installed VL on an 8 GB High-speed CF card with an IDE adapter and it worked fine. Problem, of course, is the write limits on flash memory. So I bought an i-Ram and 4 GB of DDR, which acts as a SATA hard drive. Battery backup keeps it alive when machine is unpowered.

The plan is to put frequently written to dirs on the i-Ram.
I'm thinking 200 MB for /var, 1 GB for /tmp and the rest for /home/myself.

Anyone have thoughts as far as the amount of space to allocate, and any other directories that get written to often?
Logged
rbistolfi
Packager
Vectorian
****
Posts: 2291


« Reply #1 on: October 24, 2007, 05:39:23 am »

I have no suggestion about your issue, but a request: could you keep a journal about that? Have those things documented could be great. I extend the request to anyone trying cool / funny /crazy stuff with vl.
BTW, I am very sensitive to noise too, too much rock left me with a beep in my ear all the time Sad   
Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."
Jorge Luis Borges, Avatars of the Tortoise.

--
Jumalauta!!
saulgoode
Vectorite
***
Posts: 340



« Reply #2 on: October 24, 2007, 05:54:28 am »

Would it not be preferable to use 'tmpfs' instead of placing /tmp on a ramdisk? That way, only the RAM needed would be tied up.
Logged

A complex system that works is invariably found to have evolved from a simple system that works.
nightflier
Administrator
Vectorian
*****
Posts: 4038



« Reply #3 on: October 24, 2007, 06:21:24 am »

A log is a good idea. I can add to the one from a few years back:  http://stefanussen.net/qpc.txt  I never learn  Roll Eyes

I currently do have tmpfs enabled. Not quite sure how that works. Files still show up in /tmp.



Logged
saulgoode
Vectorite
***
Posts: 340



« Reply #4 on: October 24, 2007, 08:21:05 am »

I currently do have tmpfs enabled. Not quite sure how that works. Files still show up in /tmp.

It is similar to a RAMDISK but the memory is not pre-allocated; it is allocated as needed and freed when files are deleted. When you exceed the available memory (either system RAM is in use or you exceed the 'tmpfs' maximum allocation), swap is used (you could maybe have an IDE drive or USB stick dedicated to swap just in case you reached this condition).

Logged

A complex system that works is invariably found to have evolved from a simple system that works.
nightflier
Administrator
Vectorian
*****
Posts: 4038



« Reply #5 on: October 24, 2007, 09:09:34 am »

Okay.. I have been running without swap since I installed 5.8 (part of the experimentation leading up to this). It has given me no problems. Normally less than half of my RAM (1 GB) is in use.

Won't be an IDE disk involved, I will use my network server for file storage.

I'm still somewhat confused about tmpfs. I changed mount point from /dev/shm to /tmp and things seem to work okay. I understand that now everything in /tmp runs in RAM. May this cause problems if something expects /dev/shm to be mounted tmpfs?
« Last Edit: October 24, 2007, 09:45:30 am by nightflier » Logged
saulgoode
Vectorite
***
Posts: 340



« Reply #6 on: October 24, 2007, 09:57:18 am »

I'm still somewhat confused about tmpfs. I changed mount point from /dev/shm to /tmp and things seem to work okay. I understand that now everything in /tmp runs in RAM. May this cause problems if something expects /dev/shm to be mounted tmpfs?

/dev/shm is used by POSIX (you shouldn't mess with it). You can make any directory a 'tmpfs' by using the 'mount' command.

To create a tmpfs-based /tmp, use the following:

mount -t tmpfs tmpfs /tmp

To create a tmpfs-based /var, use the following:

mount -t tmpfs tmpfs /var

When you first mount the directory, it will be empty and you need to populate it. When you unmount the directory, you will lose all the files in it, so you will want to make sure that you save everything that is important before unmounting.

Logged

A complex system that works is invariably found to have evolved from a simple system that works.
nightflier
Administrator
Vectorian
*****
Posts: 4038



« Reply #7 on: October 24, 2007, 10:36:31 am »

/dev/shm is used by POSIX (you shouldn't mess with it).
I kinda had a feeling you'd say that  Wink

Anyways, now I getting somewhere. I added this line to fstab:
tmpfs   /tmp    tmpfs defaults 0  0
and /tmp is now in RAM. 

With this setup, I'm thinking that adding more system RAM would be a good idea, as more of it will be used.

I also like your idea about adding a USB stick for swap. Since it will rarely or never be used, it could be low speed/capacity. This should not affect performance of the system and be cheap insurance?
Logged
larkl
Member
*
Posts: 30


« Reply #8 on: October 24, 2007, 02:54:03 pm »

Have you looked at the Damn Small Linux forum re- "frugal install" without a HD?  Might give you some information that'll help.  I used frugal for a year or so, but the image was on a dhard drive. 
Logged
rbistolfi
Packager
Vectorian
****
Posts: 2291


« Reply #9 on: October 25, 2007, 06:45:50 am »

You can make any directory a 'tmpfs' by using the 'mount' command.

To create a tmpfs-based /tmp, use the following:

mount -t tmpfs tmpfs /tmp

To create a tmpfs-based /var, use the following:

mount -t tmpfs tmpfs /var

Sorry for the interruption but I find this interesting. This means that, for example, if I have a very slow hd, and I want to improve access to some files I write to very often, can I mount a dir of my liking as a tmpfs and drop files in it?
Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."
Jorge Luis Borges, Avatars of the Tortoise.

--
Jumalauta!!
saulgoode
Vectorite
***
Posts: 340



« Reply #10 on: October 25, 2007, 09:23:28 am »

Sorry for the interruption but I find this interesting. This means that, for example, if I have a very slow hd, and I want to improve access to some files I write to very often, can I mount a dir of my liking as a tmpfs and drop files in it?

First let me say that for Nightflyer's system, mount /var as a tmpfs would not be advisable -- I lost track of what he was trying to accomplish (/var as tmpfs would only be preferable if he only had CF for permanent storage). I imagine Nightflyer is aware of this but wished to correct my mistake.

Rbistolfi, tmpfs is very nice for the situation you describe, particularly if you do a lot of modifications to the files before you need to commit them. In some situations, however, Linux's native caching handles things just as efficiently (when there is a lot of data being accessed multiple times, but not being modified).

As an example, I do a bit of video editing using the GIMP Animation Package. This program works by treating a video as a sequence of separate image files and a 3-minute video might be 20,000 files. When I apply a filter, for example, each of those files gets loaded into the GIMP, the filter applied, and the file written back to disk. Each modification I make requires this loading and saving of the files. By creating a tmpfs directory and copying all of the files to it, I see about a four-fold increase in speed (and a lot less disk wear). After I am done, of course, I need to move the edited files to the harddrive.

Personally, I don't like to keep these tmpfs directories around too long because they detract from the kernel's caching and swapping abilities (I don't have oodles of RAM). But they are a powerful tool in certain scenarios and they certainly would seem to obviate the need for ever creating a fixed-size "ramdisk".

I also like your idea about adding a USB stick for swap. Since it will rarely or never be used, it could be low speed/capacity. This should not affect performance of the system and be cheap insurance?

I have always liked having some swap available, regardless of how much RAM I have. If it is never used, no big loss. However, if a program has a memory leak that eventually uses up all your system RAM, at least when you start thrashing your swap you will have time to take graceful corrective measures (ie, kill the offending process) and avoid a random shutdown of some unrelated program/daemon. Cheap insurance, indeed. Smiley
Logged

A complex system that works is invariably found to have evolved from a simple system that works.
caitlyn
Packager
Vectorian
****
Posts: 2876


WWW
« Reply #11 on: October 25, 2007, 10:15:26 am »

There are a number of things you can do to reduce I/O to the flash device.

1.  Mount the volume with the noatime option so that access times are not written.
2.  Use xfs as your filesystem.  It does lazy writing more than any other fs and small temp files may never actually end up on the CF card at all -- they will rather be in memory.

My general advice on silent systems is to run an OS entirely in RAM.  In theory any distro built with the linux-live scripts (which includes the live CD versions of Vector Linux) can run with the copy2ram option provided you have enough memory.  You then only load the OS from the CF card and read and write data files.  Everything else lives in RAM.  4 GB is marginal for Vector Linux Standard entirely in RAM.  Some other similar Slackware based distros can run in 1GB or even 512MB (think Wolvix, AliXe, Slax, NimbleX, MitraX).

One of my pet projects is a "mini" version of Vector Linux Standard that will run in 512MB but it's on hold until I get settled in my new home.  The application for my project is green and silent computing -- a NanoITX system with flash storage similar to yours.  My only reason for doing this rather than running one of the abovementioned distros is that I still really like Vector and some of the tools developed for VL better than anything else I've run into.

HTH...
Logged

eMachines EL-1300G desktop, 1.6GHz AMD Athlon 2650e CPU, 4GB RAM, nVidia GeForce 6150 SE video
CentOS 6.5 (will try VL64-7.1 soon)

Toshiba Satellite A135-S4727,  Intel Pentium T2080 / 1.73 GHz, 2GB RAM, Intel GMA 950

HP Mini 110 netbook, 1.6GHz Intel Atom CPU, 2GB RAM, Intel 950 video, VL 7.1
caitlyn
Packager
Vectorian
****
Posts: 2876


WWW
« Reply #12 on: October 25, 2007, 10:19:54 am »

Have you looked at the Damn Small Linux forum re- "frugal install" without a HD?  Might give you some information that'll help.  I used frugal for a year or so, but the image was on a dhard drive. 

Wolvix supports frugal install (with a modified DSL install script) as well and is more like Vector Linux -- current kernel and apps, based on Slackware, etc...  Slax and many other distros based on the linux-live scripts actually only support frugal installation with a provided script and don't support a normal installation.  Tomas (the developer of Slax and linux-live) doesn't believe such distros should be installed in a conventional way.

In any case, frugal installation only saves space on the compact flash card and with 8GB available I don't think that's his issue.  It also allows the OS to be run from a read-only filesystem (good for security) that's compressed.  The real issue is reducing I/O to extend the life of the flash device. 
Logged

eMachines EL-1300G desktop, 1.6GHz AMD Athlon 2650e CPU, 4GB RAM, nVidia GeForce 6150 SE video
CentOS 6.5 (will try VL64-7.1 soon)

Toshiba Satellite A135-S4727,  Intel Pentium T2080 / 1.73 GHz, 2GB RAM, Intel GMA 950

HP Mini 110 netbook, 1.6GHz Intel Atom CPU, 2GB RAM, Intel 950 video, VL 7.1
nightflier
Administrator
Vectorian
*****
Posts: 4038



« Reply #13 on: October 25, 2007, 11:26:40 am »

This is exactly the kind of brainstorming I hoped for, and this community is not letting me down  Smiley

I'm wanting to get rid of the hard drive because of the noise/power/heat involved, but at the same time I want Vector as I'm used to it, not a frugal install (I want my cake and eat it too).  Wink

Experimenting with /tmp in RAM, no swap, I find that K3B still can burn disks, even though temp space is less than the image size. This is encouraging, must mean that it "streams" the info without the need for a full image on disk.

I'm taking this one step at the time and having fun in the process. Keep those suggestions coming!
Logged
rbistolfi
Packager
Vectorian
****
Posts: 2291


« Reply #14 on: October 25, 2007, 11:37:15 am »

Thank you very much, saulgoode, you have teaching abilities, you should consider writing a book  Smiley.

Quote
Personally, I don't like to keep these tmpfs directories around too long because they detract from the kernel's caching and swapping abilities (I don't have oodles of RAM). But they are a powerful tool in certain scenarios and they certainly would seem to obviate the need for ever creating a fixed-size "ramdisk".

I see. I was reading some stuff about swappiness at kerneltrap, following some of your posts, I think this is pertinent to that discusion. One of the arguments against reduce swappiness is about the impact on the file cache system. Perhaps is about evaluating what is more important in a particular situation. The discussion is failing trying to set an universal law, for every possible scenario. tmpfs looks like something flexible and easy to use. Plus, you can put the files of your choice there, instead playing with a global variable.

Quote
I'm taking this one step at the time and having fun in the process. Keep those suggestions coming!

Good work there, I enjoy the thread too. Keep us informed.
Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."
Jorge Luis Borges, Avatars of the Tortoise.

--
Jumalauta!!
Pages: [1] 2 3
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!