File storage server

[Trev]

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.

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.

[Trev]

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.

[Trev]

@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.

[Trev]

Drobo sounds very cool (and looks cool, too), but the drives are still part of an array, and it has more overhead than RAID5....

[Trev]

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.

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.

[Trev]

@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.)

[Trev]

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.

[Trev]

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.