DIY NAS + database: boot off USB and spin down hdd?
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
DIY NAS + database: boot off USB and spin down hdd?
Hi,
I am about to build a little NAS, not really for streaming media but for sharing files, recieving backups and running a couple of database engines (Postgre and eventually MySql).
It will be very common that the NAS spends 2 or 3 days without being accessed so I was wondering if I could do someting to avoid having the hdd spinning at all time.
First I thought about system hibernation but I guess it can be troublesome having the DB engines there, so I am thinking about booting the OS off a USB pendrive (*) and storing my user data and DBs in a separate hard drive.
Then I remebered that in the past I had tried to make my hard drive spind down when idle and the OS just kept spining it on, eventually after some googling it was apparent that spining down the root fs was not possible or at least not realistic.
Has anyone tried and succeded at such configuration? (USB, Databases, spindown)
anyone has some insights to share?
(*) As I am not in the USA reasonable CF cards are rather expensive for the space they provide and SSD are almost prohibitively expensive, so a decent USB pendrive would be a better option.
I came in this topic to suggest you use a CF card in a SATA/IDE adapter...but then you said you don't want to do that.
I'm sure the USB flash drive would work, but it's hardly ideal. Most are very slow, and they are certainly not intended for long-term usage. There is a very good reason that CF is more expensive.
I recongnise that i am trying to keep the cost as low as possible, but if it really makes a big difference I might bite te bullet and go for a CF card. Then again, from time to time I use full blown distros from USB pendrives and I can tolerate their performance.
I guess I should look into theirs current prices...
I vaguely remember that there were some recommended types for this and others that were too slow or to fragile?
Depending on the amount of data you wish to store this could be an ideal project for a Raspberry PI with a suitable sized SSD card. Would be totally silent in operation and low power consumption.
I just looked into the current costs of SSDs and CFs... CF is kinda expensive for the amount of space they offer I could stretch to a 8 GB but runing at X266, which doesn't look like a great performer really, but then I need the adapter and the combo raises the total cost about %50
SSD are simply too expensive here for their capacity. In my case that money would *way* better spent in a 1 TB hdd.
@TenTenths
I had considered that kind of hardware but decided that I need something more mainstream so I won´t have to dedicate so much time to set up the functions I want.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.