Amiga.org

Coffee House => Coffee House Boards => CH / General => Topic started by: pyrre on January 10, 2009, 11:39:08 PM

Title: File storage server
Post by: pyrre on January 10, 2009, 11:39:08 PM
I am about to set up a file server.
But.
I have specific needs.
I want to have disks in. sort of a "cluster".
I do not want to run ANY KIND of raid.
But i want the ability to add or remove disks as i see fit.
And the disks MUST be available in the same mountpoin/share...
Do any of you have any suggestion to what os and what software to use?
Title: Re: File storage server
Post by: X-ray on January 11, 2009, 12:40:19 AM
"I do not want to run ANY KIND of raid.
But i want the ability to add or remove disks as i see fit."
------------------------------------------------------------

I don't know how you can remove disks as you see fit without having them in a RAID.
Title: Re: File storage server
Post by: pyrre on January 11, 2009, 12:54:29 AM
Maybe you misunderstood... :-)

not hotswaping.
In a raid you need all disks to bee equal size.
And in raid 0 you have absolutely no data security. if one disk fails all data is lost.
In raid 5 you do not use all available space for data storage. Some space goes away in redundancy.

I just want to add several disks into one logical drive.
And the ability to add disks to make the storage space larger. or change disks as i buy newer end bigger ones.
And some sort of fail safe. if one disk dies only the data on that disk is lost, and the drive is replaceable.

Hope that clarifies my intentions...
Title: Re: File storage server
Post by: X-ray on January 11, 2009, 01:22:12 AM
Oh I see, you don't mind losing the data on the one that dies.
Title: Re: File storage server
Post by: pyrre on January 11, 2009, 02:32:11 AM
well... I do mind...
but over the past years i have been working on computers, only one disk has died of natural causes.
And it made "clicking" sounds for 6 months before it really died... Normally plenty of times to replace it.
However.
I cannot afford purchasing a large number of drives at once. and saving up to do so takes much too long time.
I just want the possibility to ad disks as i go along.
And of course replace failing disks...

Secure storage of data is already taken care of.
i just need a large storage for movies and tv series...
(most of wich is purchased, and i do not like "disk jockeying"  :-D )
Title: Re: File storage server
Post by: X-ray on January 11, 2009, 12:25:06 PM
Okay, then get a RAID controller that supports JABOD (Just a Bunch of Disks).
You can have odd sizes, and you don't need drives on the controller for redundancy.
The trouble is, if you lose a drive, there is no neat way to get the data back in place.
Title: Re: File storage server
Post by: kevh100 on January 11, 2009, 02:52:24 PM
As X-ray said you really need some level of redundancy when dealing with multiple drives in a pool unless you:
a) are feeling lucky punk.
b) only have data which can be safely lost if you had a problem
or
c) keep good backups elsewhere

You don't need a raid controller that does JBOD though. You can use logical volumes on linux with LVM (http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)) or ZFS (http://en.wikipedia.org/wiki/ZFS) on Solaris/OpenSolaris with any device that the OS can see using disks attached to any controller (e.g. some on IDE some on SATA and some on USB)

ZFS is very easy to use and get to grips with and offers many cool features (Filesystem compression, incremental snapshots, 256bit checksums on data).There are a few downsides, such as ZFS doesn't allow you to remove disks from a pool (yet). You can grow it using odd sized disks in any arrangement though. OpenSolaris works best on fairly modern hardware though and can need lots of RAM (>1GB) to get the best performance. Learning OpenSolaris is quite trivial and there is not too much of a learning curve. OpenSolaris doesn't support as much hardware as Linux either. You can get ZFS on linux but it's still has some issues.

I'd stick with LVM if I were you simply on the basis that you might possibly need to reduce the size of your data pool.

Kev
Title: Re: File storage server
Post by: pyrre on January 11, 2009, 03:21:26 PM
The thought strike me of using Linux and LVM.
The computer to use as file server is a PIII 1000 with 768MB ram.

So far it has 8 disks of total 425 GIG.
Which will be replaced as i purchase bigger disks...
For starters i will test different OS and see what fits best.

according Linux.
How difficult is it to learn how to use Linux?
How may i reduce footprint of os and tweak the OS for my specific needs and hardware?
Title: Re: File storage server
Post by: Oliver on January 12, 2009, 11:50:05 AM
Learning Linux is a widely various task. Have you had any background in Unix type systems? Will this be a dedicated fileserver? Will it be running on a wired NIC (some wireless interfaces are a PITA with Linux driver support)?

In terms of how streamlined your server could be, it also depends on what else you might need to do with the machine, and also if you need a GUI. Running a Linux kernel on your hardware shouldn't be any problem. You could quite possibly run a dedicated server installation, without any of the usual desktop/workstation features. It depends on what you are comfortable with, though. I think using a more fully featured distribution may be easier for you to come to terms with the system.

You could try learning a bit about Linux with a virtual installation somewhere, or with a live CD/DVD on your server hardware, just to get used to it for a while. This is a text (http://tille.garrels.be/training/tldp/) which I found handy when first learning to use Linux based systems. From memory, I don't think it goes into running a file server. However, it's not bad for getting started.
Title: Re: File storage server
Post by: pyrre on January 12, 2009, 08:06:08 PM
It will mainly be running a file server.
hopefully with a HTTP interface.
if the server runs gui or not does not really matter.
Linux based "openfiler" is a probability.

I have absolutely no previous linux or unix experience.

The server setup:
Intel PIII 1000 CPU
Via TUV4X motherboard
768MB ram
silicon image PCI IDE controller (not raid)
NVidia GF TI4200 (the smallest i had available)
CNet gigabit wired Ethernet adapter.
Disks:
10 gig fujitsu (system)
13,5 gig IBM
20 gig Maxtor
40 gig WD
40 gig WD
80 gig WD
120 gig WD
120 gig WD

All the disks will be used for testing and learning the os..
and will be replaced later on as economy seems fit... :-)
Title: Re: File storage server
Post by: persia on January 12, 2009, 08:33:36 PM
Why serve files via http?  Wouldn't SMB be a better choice?
Title: Re: File storage server
Post by: pyrre on January 12, 2009, 09:08:30 PM
SMB will be for sharing the files in the network, yes.
The GUI for configuring and using the server itself will be run on HTTP
Title: Re: File storage server
Post by: Trev on January 12, 2009, 11:36:26 PM
Under Windows 2000+, you can mount drives as directories instead of drive letters. That's one simple way of adding storage. I posted something on how to arrange a Windows file system in a way similar to a standard Unix layout in a very old post. [Searching...] This is rather old and perhaps full or errors, but I'm not going to edit it. :-) Enjoy, though.

Quote

You could follow a scheme similar to Glaucus' but take better advantage of NTFS:

System Volume (Mounted as C:)
Application Volume (Mounted as C:\Program FIles)

Data and temp stuff gets tricky, 'cause most people just use the defaults. On Windows XP, the temp and personal folders are located here:

C:\Documents and Settings\%USERNAME%\Local Settings\Temp
C:\Documents and Settings\%USERNAME%\My Documents

(Really, it's %USERPROFILE%\..., but %SystemDrive%\Documents and Settings is the default location for storing profiles.)

Personally, I just format the whole drive as a single partition and use directories to organize stuff. A good compromise might be setting up two volumes:

System Volume (C:)
Data Volume (E:)

And when your data volume gets full, you can just throw in another drive and append the new space to E:. The key is to think logically and not get stuck on how things are layed out physically. With a good, *ahem*, backup routine, it really shouldn't matter.

Trev

***

Mounting volumes as a folder (or both a folder and a drive letter or as a combination of multiple folders and drive letters) is a feature of NTFS, so all your volumes should be formatted as NTFS. Before you begin, decide how much space you want to use for each volume.

In this example:

System Volume: 20 GB
Application Volume: 80 GB

1. Install Windows XP Professional as per usual, manually creating a 20 GB partition for the system volume. Quick-format this partition as NTFS.

2. After the installation is complete, copy "C:\Program Files" to a new folder on the same drive. We'll use the default name of "C:\Copy of Program Files" for this example.

The "Program Files" folder is a normal folder; however, Windows Explorer prevents this folder from being renamed. To facilitate our change, we'll need to make two temporary registry changes.

3. Run regedit.exe and change the following values (you can copy and paste this into a .reg file if you'd like):

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion]
"CommonFilesDir"="C:\Copy of Program Files\Common Files"
"ProgramFilesDir"="C:\Copy of Program Files"

4. Reboot.

You may notice some user interface weirdness at this point. Don't worry. It will be resolved when the change is complete.

5. Delete the contents of "C:\Program Files". You should have an empty folder at this point.

6. Start the Computer Management MMC snap-in (Start | Settings | Control Panel | Administrative Tools | Computer Management).

7. Select the Storage | Disk Management node in the tree view.

In our example, we're going to use 80 GB of free space on our system drive to create a new volume. Some of the following text is paraphrased from the Disk Management help file.

8. Right-click on the unallocated region and select New Partition on the context menu.

9. In the New Partition Wizard, click Next, click Primary Partition. When prompted for the partition size, enter 80 GB, and then follow the instructions on your screen.

10. Right-click on the new partition and select Format from the context menu.

11. Format the new partition using the NTFS file system.

12. Right-click the formatted partition and select Change Drive Letter and Paths from the context menu.

13. If there's a drive letter listed, highlight it and click Remove.

14. Click Add. Click Mount in the following empty NTFS folder, and type "C:\Program Files" in the text box. Click OK.

The new partition is now mounted under "C:\Program Files".

15. Copy the contents of "C:\Copy of Program Files" to "C:\Program Files". Keep "C:\Copy of Program Files" around for later use.

16. Run regedit.exe and change the following values (you can copy and paste this into a .reg file if you'd like):

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion]
"CommonFilesDir"="C:\Program Files\Common Files"
"ProgramFilesDir"="C:\Program Files"

17. Reboot.

Voila! You should be mostly done. At this point, you should verify that the permissions on all files and folders under "C:\Program Files" match the original permissions under "C:\Copy of Program Files". You can delete the copy when you're done.

I haven't actually tested these instructions, but theoretically, they should work. Let me know if you have any problems. . . .

Trev

***

Quote:
--------------------------------------------------------------------------------

I assume you do the same for My Documents.
--------------------------------------------------------------------------------


I probably wouldn't do this for My Documents, but I might do it for "C:\Documents and Settings".

As a comparison to Un*x, you could make the following associations:

/ - "%SystemDrive%"
/bin - "%SystemRoot%\System32"
/etc- "%SystemRoot%\System32\Drivers\etc"
/home - "C:\Documents and Settings"
/opt - "C:\Program Files"
/sbin - "%SystemRoot%\System32"
/usr - "C:\Program Files"
/var - "%SystemRoot%\Temp"

Using those associations, you could use the procedure above to partition your file system in a manner similar to the way you would do it in Un*x. The only exception is %temp%, which varies from user to user. But in general, user temp stuff should go in the user's profile, and system temp stuff (specifically, temp file created by the LocalSystem account) should go in "%SystemRoot%\Temp".

Quote:
--------------------------------------------------------------------------------

If at a later time you add a second hard drive, could you mount it to the same directory, to increase the size of the mounted directory (for example, add another 40 gigs to c:\Program Files) ???
--------------------------------------------------------------------------------


Absolutely. In NTFS V5 lingo, this is called a spanned volume. The bad news is that you need to convert your basic disks to dynamic disks and this isn't supported by Windows XP Home. Furthermore, only Windows 2000, Windows XP Professional, and Windows 2003 can see dynamic volumes. (You could try Sysinternals' NTFS for Windows 98. NTFSDOS Professional should work as well.)

Take a look in the Disk Management help under the following topics (you'll have to remove the "http://" for these links to work):

Change a basic disk into a dynamic disk
Manage spanned volumes

You can only span a volume 32 times, and you can't expand a volume that has been striped or mirrored using the operating system's software. In the server world, we only use spanned volumes on hardware RAID (either mirrored or with parity--not RAID 0) arrays that are routinely backed up.

Trev

***

Quote:
--------------------------------------------------------------------------------

That is actually the coolest Windows tip I've heard for a very long time. I didn't know Windows allowed one to mount volumes at arbitrary locations, that was what I believed to be one of Linux's major advantages over it. So much for that I guess Since when has that been possibe? NT4, Win2K or WinXP?
--------------------------------------------------------------------------------


Windows 2000 Professional was the first OS to support it directly from the user interface. These are called Volume Mount Points, and they're supported by NTFS v5 and later. They're implemented in the OS using reparse points, which have been available for some time. Reparse points also support hard links and junctions at the file system level. (These aren't the same as shortcuts, which are just IShellLink objects persisted to disk.)

Behind the scenes, Windows NT has a fully hierarhcical object namespace similar to Un*x's file system space. Disk volumes are a very small part of that namespace. For example, "C:" is actually "\??\C:", which is typically a symbolic link to "\Device\HarddiskVolume1".

If you take away all the Microsoft marketing BS, Windows is actually a pretty spiffy OS. And really, the engineers that work for Microsoft are friendly, helpful people (who sometimes like to give away t-shirts and Microsoft video games).

Trev

***

If you're only dealing with Windows XP Professional (and frankly, unless you're using some kind of proprietary or turn-key solution or doing system administration or OS-specific testing and development, there's no reason to be using another version of Windows), then the drawbacks (what are they again?) of dynamic volumes shouldn't make a difference. The Logical Disk Manager subsystem was designed by Veritas and licensed by Microsoft, and it's definitely a more robust solution than PC BIOS based partitioning (although the system partition retains an entry in the partition table after the disk has been converted).

Now, about spanned volumes. The tagged on volumes (for lack of a better phrase) are not treated as separate entities with respect to volume mount points. In other words, you can't assign a separate drive letter to the additional space. When a volume is spanned across multiple devices, the space is used in the order in which the volumes were added, so disk0 will be filled up before disk1. The only safe way to remove a disk from a spanned volume is to back up the entire volume, delete it, remove the disk, recreate the volume, and restore the data. So there are some drawbacks there.

The only reason you wouldn't want to convert a basic disk to a dynamic disk is if you're going to access that disk from other operating systems. If you're only using NTFS partitions, then the point is moot anyway, as you can't normally access NTFS partitions from other operating systems.

So, after you've backed up your data, go for it!

EDIT: Can we change the displayed topic of this thread?

EDIT2: I definitely don't mind the questions. It's nice to feel useful.
Title: Re: File storage server
Post by: persia on January 13, 2009, 01:38:53 AM
Yeah, best to can the GUI.  I run a small filesever using Gentoo Linux.  It's straight forward and easy to maintain, of course there's no redundancy and no protection against failure, but it works well if you only have a few computers accessing the files and you have some other method of backup.

I'm not sure what you need to change, file servers in the home are a set 'em and forget 'em technology.

 
Title: Re: File storage server
Post by: Trev on January 13, 2009, 02:09:21 AM
If you don't want to run Windows, don't want to configure the latest version of Samba, and don't care whether or not your file server is 100% SMB-compatible or performs well in a high-bandwidth, low-latency environment (most consumer NAS products do not), then just invest $150-$300 in an off-the-shelf NAS solution from Iomega, Seagate, or some other vendor. But, you probably want other nice features like UPnP, mDNS (Bonjour), etc.
Title: Re: File storage server
Post by: pyrre on January 13, 2009, 04:07:54 AM
@ Trev
I just run 2000 server and converted disks to dynamic disks.
In that matter all disks were spanned as one logical volume. however. If i wish to remove one disk from the volume i break it apart and loose ALL data. UNWANTED.
From earlier experiences I do not want do mount drives in folders. I have had problems of data corruption at some point.
This last time i tried 2000 server it had problems with data transfer rates. It was not able to stream data over gigabit Ethernet to my mediacentre xbox.
Freenas did, on the same hardware.

I have now installed ubuntu 8.04 on my server.
Will in the next days try use LVM filsesystem and see how it works out.
A friend of mine standing in the same position as me, wanting to build e cheap end easy to expand fileserver is testing linuxbased openfiler (http://www.openfiler.com/). If ubuntu does not work out for me i will try open filer as well...
If  freeNAS (http://www.freenas.org/) was stable running vinum volume manager (http://en.wikipedia.org/wiki/Vinum_volume_manager) I would have choset it..

EDIT:
Messed up with the different types of volume managers... :-)
Title: Re: File storage server
Post by: persia on January 13, 2009, 05:05:33 AM
So you're going with Linux.  I would have chosen a different distro, did you compare distros or just went with the flavour of the month?
Title: Re: File storage server
Post by: Trev on January 13, 2009, 07:38:49 AM
@pyrre

Yeah, spanned volumes aren't ideal (I think I commented on the limitations somewhere in that old message). You could have partitioned the individual disks and mounted them as directories, however:

C:\Data\MyFristDrive -> \Device\HarddiskVolume1
C:\Data\MySecondDrive -> \Device\HarddiskVolume2
etc.

Whether or not Windows 2000 (or any other OS) performs well using SMB/CIFS over GbE depends on the TCP/IP configuration of both the client and the server (in particular, the requisite receive window size, e.g. 1,000,000 bytes for GbE with 1ms RTT--Google "bandwidth delay product"), MTU (Windows limits the MTU to the host requirements RFC minimum when it can't do path MTU discovery across a router), which version of SMB/CIFS is used by the client, and the overall speed of the system.

Windows 2000 does not tune itself for high-speed networks out of the box. You have to do a bit of tweaking to get it there. The same can be said of most TCP/IP stacks.

Without reading from cache, you're probably not going to fill a GbE link using a single disk, especially an older model spinning at 5400 RPM.

You want a file system that allows its internal structure to be distributed among disks and loaded/unloaded as disks join/leave a disk group, dynamically updating information like display information like directory listings and free space at the same time.

EDIT: And rather than implement a NAS, you may want to look into SAN hosts (iSCSI or ATAoE over GbE is probably the cheapest access method) and cluster file systems, i.e. file systems that appear local to and can be accessed by disparate hosts simultaneously. That coupled with dynamic attaching/detaching of physical disks would be ideal, I suppose.

EDIT2: Hmmm. GlusterFS http://www.gluster.org/. Check out the aggregation feature, which really stems from their decentralized approach. Looks very promising.
Title: Re: File storage server
Post by: motorollin on January 13, 2009, 08:54:09 AM
Drobo (http://www.drobo.com/)

We had one of these for some time and it's absolutely brilliant. It warns you when the array is getting full. You just pull out a disk and it carries on working (but loses redundancy). Plug another drive in, and it rebuilds the redundancy with the new disk. All of this is on the fly. There's a video somewhere (maybe on that site I linked to above) which shows it doing all of this while playing a video from the drive. It never misses a frame while the disks are being swapped in and out.
Title: Re: File storage server
Post by: Trev on January 13, 2009, 05:17:43 PM
Drobo sounds very cool (and looks cool, too), but the drives are still part of an array, and it has more overhead than RAID5....
Title: Re: File storage server
Post by: motorollin on January 13, 2009, 05:37:47 PM
Quote
Trev wrote:
Drobo sounds very cool (and looks cool, too), but the drives are still part of an array

Yes, but the disks don't have to be matched. You can stick any size drive in there and it will work.

Quote
Trev wrote:
and it has more overhead than RAID5....

In terms of the capacity required for redundancy?
Title: Re: File storage server
Post by: Trev on January 13, 2009, 11:37:26 PM
Quote

Yes, but the disks don't have to be matched. You can stick any size drive in there and it will work.


You can use any size disk in an array on most array controllers, but the largest logical disk size will be n times the size of the smallest disk (or the largest amount of equal available space across all disks). A lot of array controllers are very flexible, too. Let's say you have three 500GB disks and three 250GB disks. You could create one 1TB array (3x500GB) and one 500GB array (3x250GB), one 1.25TB array (6x250GB) and one 500GB array (3x250GB from the unused half of the 500GB disks), etc., so there are ways to maximize your available storage.

Logical disks can usually be expanded and converted to different RAID levels as well. How the new storage is made available to the user depends on the file system and operating environment.

Quote

In terms of the capacity required for redundancy?


Yeah. But it's still a very cool product, especially from an ease of use standpoint. If you think of it in terms of wasted storage when using different sized disks versus wasted storage when using same sized disks in a RAID5 array, then the Drobo has a lot to offer.
Title: Re: File storage server
Post by: pyrre on January 14, 2009, 10:04:54 AM
Or, you could just show 4 1.5TB disks in the controller...
one at the time..
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 10:36:00 AM
I've just opted for the easy route... And bought a couple of TB S-ATA drives... They are only £70... I plan to try an dump all the random odd sized ATA disks that I currently have...
Title: Re: File storage server
Post by: pyrre on January 14, 2009, 03:54:55 PM
@ bloodline

What do you mean by dump?
As in trowing them away?
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 04:11:23 PM
 
Quote

pyrre wrote:
@ bloodline

What do you mean by dump?
As in trowing them away?


No, I'll archive some stuff on them and put them in a cupboard. I'm not sure how much longer I'll have any mobos with P-ATA interfaces on... I'll have to keep one around I guess... :-(
Title: Re: File storage server
Post by: motorollin on January 14, 2009, 04:17:27 PM
Quote
bloodline wrote:
I'm not sure how much longer I'll have any mobos with P-ATA interfaces on... I'll have to keep one around I guess... :-(

Use an Amiga! :-D
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 04:29:32 PM
Quote

motorollin wrote:
Quote
bloodline wrote:
I'm not sure how much longer I'll have any mobos with P-ATA interfaces on... I'll have to keep one around I guess... :-(

Use an Amiga! :-D


:-D not sure how my little A1200 will cope with my assorted array of old HD's ranging from 30gig to 300gig... All soon to be formatted HFS+...

I will keep an old PATA->USB2 converter around should I need to recover any data stored on the drives... At the moment I also have a pair of 80gig drives in a raid0... Using some weird Nvidia raid BIOS feature... That will have to be deraided :-/
Title: Re: File storage server
Post by: motorollin on January 14, 2009, 04:33:31 PM
Quote
bloodline wrote:


:-D not sure how my little A1200 will cope with my assorted array of old HD's ranging from 30gig to 300gig... All soon to be formatted HFS+...

I will keep an old PATA->USB2 converter around should I need to recover any data stored on the drives...

Coward! :-P
Title: Re: File storage server
Post by: pyrre on January 14, 2009, 04:42:46 PM
I have two PCI pata controllers...
Will invest in some more... just to be sure.
However, as long as the PIII survives I'll always have a pata controller to extract files from pata disks...
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 04:43:35 PM
:lol: ok you tell me how to do it will with FFS, and...

Quote

motorollin wrote:
Quote
bloodline wrote:


:-D not sure how my little A1200 will cope with my assorted array of old HD's ranging from 30gig to 300gig... All soon to be formatted HFS+...

I will keep an old PATA->USB2 converter around should I need to recover any data stored on the drives...

Coward! :-P
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 04:43:46 PM
:lol: ok you tell me how to do it will with FFS, and...

Quote

motorollin wrote:
Quote
bloodline wrote:


:-D not sure how my little A1200 will cope with my assorted array of old HD's ranging from 30gig to 300gig... All soon to be formatted HFS+...

I will keep an old PATA->USB2 converter around should I need to recover any data stored on the drives...

Coward! :-P
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 04:44:10 PM
:lol: ok you tell me how to do it will with FFS, and...

Quote

motorollin wrote:
Quote
bloodline wrote:


:-D not sure how my little A1200 will cope with my assorted array of old HD's ranging from 30gig to 300gig... All soon to be formatted HFS+...

I will keep an old PATA->USB2 converter around should I need to recover any data stored on the drives...

Coward! :-P
Title: Re: File storage server
Post by: motorollin on January 14, 2009, 04:44:46 PM
Quote
bloodline wrote:
:lol: ok you tell me how to do it will with FFS, and...

Ok! PCMCIA 802.11B card, AmiTCP and SAMBA server. Surely it couldn't be *that* slow and unreliable? ;-)
Title: Re: File storage server
Post by: bloodline on January 14, 2009, 05:01:37 PM
Quote

motorollin wrote:
Quote
bloodline wrote:
:lol: ok you tell me how to do it will with FFS, and...

Ok! PCMCIA 802.11B card, AmiTCP and SAMBA server. Surely it couldn't be *that* slow and unreliable? ;-)


Well.. It's the only being able to use about 0.02% of the total drive space that would be the most concern :-)
Title: Re: File storage server
Post by: motorollin on January 14, 2009, 05:15:37 PM
Quote
bloodline wrote:
Well.. It's the only being able to use about 0.02% of the total drive space that would be the most concern :-)

Can OS4 use more? Come on, we can do this! :-D :lol:
Title: Re: File storage server
Post by: Trev on January 14, 2009, 05:31:01 PM
@pyrre

But that's the problem, isn't it? How do you effectively manage the available storage on those four 1.5TB disks? If you use something like GlusterFS, each disk's storage can be managed as an independent file system, and the cluster file system will make them appear as a single logical pool. GlusterFS requires a client, but you can use a client box to re-export the data as CIFS, NFS (barf), or whatever.

Personally, I would just eat the cost and create a simple disk array, probably RAID5. Keeping tack of smaller drivers is a serious pain in the ass, and I use virtualization rather than real hardware to explore new x86/x64 software. Right now, I have two 1TB disks in a mirror. Everything else is on a shelf. (The Amigas do their own thing, however, mostly with old and small 2.5" disks.)
Title: Re: File storage server
Post by: pyrre on January 14, 2009, 05:46:08 PM
@ Trev

I have no economics now to purchase disks nor any controller.
That will have to come over time.
In the meantime i will have to coop with the diskspace i have in my main computer. And as soon as i can afford purchasing new disks i will expand my server.
For now i test out different operating systems and see what fits my needs.

Any Microsoft based OS is out of the question.

A Redhat derivative called open filer suits my needs as a file server. In open filer i can add as many disks as LVM will allow. and when i can afford new disks i can swap them at any time with any disk i wish. thus expanding the storage space.

And when i have enough disks to run raid i will convert the storage array into a raid. If i have to backup data i am not sure. Have not tested that option yet.
Need some help from a friend to do so...

EDIT:
Damn.. backup and reformat has to be done to convert to a raid... :-(
Title: Re: File storage server
Post by: Trev on January 15, 2009, 02:03:06 AM
I didn't actually recommend Windows, although it can be used in a fashion similar to your requirements. (You also get discretionary access control lists on your file systems, which most Unix variants do not have.)

Doesn't Linux's LVM disable journaling in file systems that support it? I know you don't care about disk redundancy, but data integrity is still important, yes? Be sure to keep those systems on an uninterruptible power supply if you have one.
Title: Re: File storage server
Post by: pyrre on January 15, 2009, 02:23:26 AM
@ Trev
Well...
cost considered, redundancy is not an issue for the moment.
when the server goes "online" i will start to save up funds to expand the storage.
But tree disks of 1.5 TB will be spared and as soon as i have a controller ready, it will be set up in a dynamic (read: expandable) raid 5.
In the meantime the storage amount i have is sufficient.
But i am trying out different operating systems. and my main concern is running and maintaining the OS...
As it looks right now, i have to get to learn a new os, linux...
Title: Re: File storage server
Post by: Trev on January 15, 2009, 07:16:49 AM
When do you get around to using RAID, do it in hardware using an add-in card, preferrably with a battery-backed read/write cache. Metadisks provide software-based RAID, so your CPU is taking care of the disk geometry logic. If you do RAID in hardware, the controller takes care of everything, and the operating system just sees one or more logical disks. Array expansion is usually performed in software provided by the controller vendor, and the new space is seen by the operating system as additional unallocated space. Whether or not you can expand the file system is up to the file system itself.

Performance-wise, keep an eye on how your RAID disks are configured. Your block/stripe size should match your intended use, and bigger is not always better.