Amahi Wiki - User contributions [en]

Greyhole

2013-05-30T01:22:20Z

JoshTheBlack: /* Important Warnings */

[[Category:apps]]
<div style="border: 1px solid #A3B1BF; padding: .8em 1em; background-color: #E6F2FF; margin: 0px 1em;">
'''NEW:''' [https://github.com/gboudreau/Greyhole/wiki/MigrateFromWHS Widows Home Server Drive Extender Migration Guide]

'''NEW:''' [[Greyhole troubleshooting]] guide
</div>

== What is Greyhole ==

[http://www.greyhole.net/ Greyhole] is Amahi's [[Storage pooling]] technology. Storage Pooling combines the space of multiple disk drives and makes them look as if they were all part of a single pool of disk space.
Specifically, Greyhole:
* Combines the space from multiple drives into a single volume
* Distributes files across all drives in the pool
* Creates multiple copies of files in admin-specified shares

This feature is installed by default, but requires a few simple steps to begin utilizing the features.

You can add additional drives to your hda and prepare them for use in Greyhole by following [[Adding a second hard drive to your HDA|this tutorial]].

To add a drive to your Greyhole storage pool. Open your HDA dashboard and navigate to the Shares tab. Then click on the Storage Pool sub-category. You will see a page similar to the one below.

== Important Warnings ==
<div style="color:darkred">You should '''never''' change or delete files in the shared directories (''/var/hda/files/*'' by default) directly on the HDA, using the terminal, or the Gnome file browser, for the shares for which you checked the ''Uses pool'' option in the Amahi dashboard. If you want to work with files on Greyhole shares on the HDA, you should [[Mount Shares Locally]].<br/>
<br/>
You should be safe reading existing files directly, or adding new files directly, as long as don't care that your new files will only be moved into the storage pool during the next check, which runs automatically at midnight (or manually using ''greyhole --fsck''). Until then, your new files will be stored in your shared directories (normally ''/var/hda/files/share_name/'').

Also, touching anything inside the '''gh''' directories that Greyhole creates at the root of your partitions is a recipe for disaster. [[Greyhole not on root | We strongly discourage you from using the root partition in a drive pool]].
</div><br/>

== Forcing an fsck ==
{{code|greyhole -fsck
greyhole -f}}
will run an fsck ONLY if the greyhole or samba configurations have changed. <br />
{{code|greyhole --fsck}}
will force a fsck.

== First things first ==

You need to go in the Settings tab, and enable '''Advanced Settings'''.<br/>
Without Advanced Settings enabled, you won't see the following page and options.

== For Storage Pool (Partitions) ==

[[File:Storage_Pool_1.png|600px]]

Select the drives you want available for your storage pool.

== Greyhole options ==

The next step is to select the share you want to replicate across the pool.

From the Shares tab, select the Shares sub-catagory. We chose the Pictures share for this tutorial.

[[File:Greyhole_Options_1.png|600px]]

Check the option for "Uses pool" and choose the number of drives to replicate this share. In this instance we have chosen to use all drives available to the greyhole pool.

Note: Greyhole is not a backup solution. If a file is removed, all copies are removed.

== Greyhole advanced options ==

You can further configure Greyhole by manually editing the following file:<br/>
'''/var/hda/platform/html/config/greyhole.yml'''

To see what options are available, and what they do, refer to the [https://gist.github.com/1379102 sample greyhole.conf] provided with Greyhole.

greyhole.yml is in in YAML format. Most of it should be easy enough to modify. The only exception would be the sticky_files (and optional sticky_into) options.<br/>
Here's an example of how those should appear:

To specify the following to Greyhole in greyhole.conf:

{{Text|Text=sticky_files <nowiki>=</nowiki> Music/
sticky_files <nowiki>=</nowiki> Videos/Movies/
stick_into <nowiki>=</nowiki> /mnt/hdd1/gh
stick_into <nowiki>=</nowiki> /mnt/hdd5/gh
sticky_files <nowiki>=</nowiki> Backups/CrashPlan/
stick_into <nowiki>=</nowiki> /mnt/hdd0/gh}}

one should specify this in the greyhole.yml file, where '''precise indentation matters''':

{{Text|Text=sticky_files:
- - Music/
- - Videos/Movies/
- - /mnt/hdd1/gh
- /mnt/hdd5/gh
- - Backups/CrashPlan/
- - /mnt/hdd0/gh}}

For your changes to be effective, you'll need to force Amahi to regenerate the greyhole.conf file. You can do so by editing a share, clicking it's path, and just clicking the Save button without actually changing the path.

== Copying data into shares for the first time ==

When you start using Greyhole, you might want to copy or move all your existing files into your new shares that use the storage pool.

Note: This is not necessary if your files are already in Amahi shares. If they are there, and you enable the ''Uses pool'' option in the Amahi dashboard, the files will start getting moved around into the drives in your storage pool during the night (starting at midnight), when the nightly storage pool check starts.<br/>
The instructions below are for users who have more data to copy into the Greyhole shares than their currently free space in the /var/hda/files/ folder.

One way to do that is to mount the shares that use the Greyhole storage pool, either on the HDA itself, or on a client computer on your local network, and copy your data from their existing location into the mounted shares.
This can be time consuming, but it is the safest way to use Greyhole.

Another way to move your files from their current location into the storage pool is to share their current location using an Amahi share that ''Uses pool'', then let Greyhole's nightly check move the files from there into the pool.

Here's a more detailed walkthrough for this method:

# Setup the Greyhole Storage Pool in the Amahi dashboard, Shares > Storage Pool page.
# Go in the Shares > Shares page. In there, make sure you have an existing share for each share you have data for. Create new ones if you need, remove the ones you don't need.
# Edit the ''path'' of each of those shares, and enter the current location of your existing data. For example, the Movies share could have a path = ''/media/External Drive/Movies''
# Enable the ''Uses pool'' option for each of your shares, and select the number of extra copies you'd like, if any.
# Now, you either need to wait for Greyhole's nightly check to start, or you can start it manually from a terminal, as root, using this command: greyhole --fsck
# Monitor /var/log/greyhole.log to see when the ''fsck'' operation is done.
# Once ''fsck'' is done, your data has now been moved into the Greyhole storage pool (in the drives you selected in Shares > Storage Pool). All that should be left in the previous location of your data (''/media/External Drive/Movies'' from the previous example) should be symbolic links pointing to the new file copies. If the previous location is just empty directories (no symlinks), do not panic. This is normal if your previous location is an NTFS or FAT partition (drive).
# Move all those directories / symlinks from there into the correct folders in /var/hda/files/share_name
# Back in the Amahi dashboard, edit the path of the shares once again, and put back ''/var/hda/files/share_name'' (i.e. the folders where you moved the symbolic links).
# If you used an NTFS or FAT partition for the previous location, you'll need another fsck to create the symlinks where they should be. Either wait for midnight, or launch it manually, from a command line, as root: ''greyhole --fsck''

You're done. All your existing data is now stored in the various drives included in your storage pool, and are accessible via the Samba shares you have defined in the Amahi dashboard.

== Adding a new drive to your HDA and storage pool ==
This wiki page discusses [[Adding_a_second_hard_drive_to_your_HDA|how to add a new drive to your HDA and to your greyhole storage pool.]]

== Drive Mounted as /media ==
Including any drive mounted as /media/Something in your storage pool is usually a bad idea.<br/>
Those mounts are created by the ''gnome-automounter'', which requires you to be logged in into X (Gnome) to become available.<br/>
This will create issues with Greyhole, which expects drives to always be available, and will take action when some of them are missing.

Follow this guide to [[Adding a second hard drive to your HDA|permanently mount your drives]], before you include them in your storage pool.

== Monitoring Greyhole ==
Sometimes you might want to monitor what Greyhole is doing, for example when writing data to your greyhole shares for the first time. Here are a few commands you can type in a terminal to follow along.

'''Scrolling view of total Greyhole operations queue:'''
{{Code|while [ 1 <nowiki>==</nowiki> 1 ]; do greyhole --view-queue <nowiki>|</nowiki> grep Total; sleep 60; done}}

'''Alternate way to watch Greyhole operations queue:'''
{{Code| watch -d greyhole --view-queue }}

'''Scrolling log of what files Greyhole is working on right now:'''
{{Code|tail -f /var/log/greyhole.log}}

'''Amahi App for watching the greyhole log in your web browser:'''

[http://www.amahi.org/apps/greyhole-logmon Greyhole LogMon]

== Convert Greyhole from SQLite to MySQL ==
Greyhole is already using MySQL in Amahi 6.0

Greyhole was previously using SQLite as the default database for queueing up tasks on Amahi. This was unique to Amahi as Greyhole was originally designed to use MySQL for this task.

There are some major performance benefits to using MySQL over SQLite when writing large amounts of files. Switching can be especially useful when moving data to Greyhole shares for the first time. For now there is a script you can run if you want to switch over. This script has been tested to be safe while Greyhole is working but should be used with discretion.

''To Convert to MySQL, run as root:''

{{Code|/usr/share/greyhole/db_migration-sqlite2mysql.sh}}

To see what DB engine is Greyhole using, do this:

{{Code|grep db_engine /etc/greyhole.conf}}

== Disable Greyhole ==
For those who do not use Greyhole, you can disable it. This is based on the fact you never have used it by enabling 'Uses pool' on any share. Recommend using extreme caution as this could have unpredictable results.

Perform the following steps as user '''root''':

{{Code|chkconfig greyhole off
rm /etc/monit.d/greyhole.conf
service monit restart
service greyhole stop}}

'''DO NOT''' attempt to remove the Greyhole package as it is a dependency of the HDA software. Doing so will break your HDA.

= Testing and Reliability =

Check out the [[Greyhole grinder]] to help make Greyhole rock solid.

= Reconnect the Greyhole storage pool =

If you upgrade and/or reinstall Amahi and need to get your drives with data on them to the new system, follow this [[Reconnect_existing_Greyhole_storage pool]] guide.

= Greyhole Troubleshooting =

Page: [[Greyhole troubleshooting]]

= Landing Zone Considerations =

The landing zone or LZ is the area where files arrive first before being distributed to their final destination. See details in the [[Greyhole landing zone]] page.

= Manually updating Greyhole for Amahi =
Page: [[Greyhole updating]]

= Emptying Greyhole Attic =
{{Code|greyhole --empty-attic}}
About the attic: The attic is used like a Recycle Bin, or Trash.
That means you'll need to manually empty it once in a while.
To do so, use the --empty-attic parameter (see above).
Another option is to create a 'Greyhole Attic' Samba share.
More details about that here: https://github.com/gboudreau/Greyhole/wiki/AboutTrash

= Moving drives/data out of Greyhole =
You may need to remove a drive from Greyhole and transfer the share files to another drive: [[Greyhole moving data out of the pool]]

= Changing the Mount Points of your Greyhole drives =
[[Changing Greyhole Mount Points]]

= Reference =
Good [http://revxatlarge.blogspot.com/2011/04/restoring-deleted-files-in-greyhole-and.html article] on Greyhole with terms explained.

Changing Greyhole Mount Points

2013-05-30T01:15:56Z

JoshTheBlack: Created page with "==DISCLAIMER== This is what worked for me. This may not work for you. I recommend testing this ONLY if all of your data is backed up and recoverable outside of greyhole. We ..."

==DISCLAIMER==
This is what worked for me. This may not work for you. I recommend testing this ONLY if all of your data is backed up and recoverable outside of greyhole.
We cannot be held responsible if you lose all of your data attempting this. YMMV.

==How To Do It==
===Stop Greyhole===
In the HDA: <br />
Setup > Settings > Servers > Greyhole <br />
Uncheck Watchdog and then press the Stop It button.
===Change Mount Points===
====Unmount your data drives====
{{code|sudo umount -a}}
Verify this completed by checking your data drives are not mounted
{{code|mount}}
====Create your new mount points====
{{code|sudo mkdir /var/hda/files/drives/bay2
sudo mkdir /var/hda/files/drives/bay3
sudo mkdir /var/hda/files/drives/bay4}}

====Backup fstab====
{{code|sudo cp /etc/fstab /etc/fstab.bak.2013.05.01}}
You could just use fstab.bak, but I prefer to have my backups dated.
====Edit fstab====
{{code|sudo nano /etc/fstab}}
Look for your mount points and change them to the new folders you want to mount the data drives in. <br />
If you haven't commented your fstab file, now's a good time for that. Here's mine:
<div style="border: 1px solid #A3B1BF; padding: .5em 1em; color: #000; background-color: #E6F2FF; margin: 3px 3px 1em 3px;">
<nowiki># <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda1 during installation
UUID=45e7d257-a7cc-4a36-9dd8-20929ad54b0e / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=c4d9f59e-1d7b-47ba-a956-e0e8a231bc10 none swap sw 0 0
########################################## Mount 4TB Seagate drive in Bay 2 from bottom ######################
UUID=05c05271-7309-4244-9dd8-8c2d6c5aeacd /var/hda/files/drives/bay2 ext4 noatime,data=writeback,nofail 1 2
########################################## Mount 2TB Seagate drive in Bay 3 from Bottom ######################
UUID=489e45f4-16ef-4a65-47ba-456e465a4b4c /var/hda/files/drives/bay4 ext4 noatime,data=writeback,nofail 1 2</nowiki>
</div>
====Remount the Drives====
{{code|sudo mount -a}}
If there are any errors from this command, FIX THEM before you reboot.<br />
Check the drives have mounted in the new mount points with:
{{code|mount}}

===Reboot===
From the HDA dashboard: <br />
Setup > Settings > Settings > click the reboot button.

===Fix Greyhole===
Some of these steps may not be necessary, but this is the path I took that got me results. <br />
Several of these steps can take a LONG time depending on how many files are on the drives you have remounted. <br />
I recommend keeping an eye on greyhole to ensure it is doing what it should.
{{code|tail -f /var/log/greyhole.log}}
Press Ctrl+Z to pause this task. Note the number in brackets or use the "jobs" command to see where it is queued. <br />
Bring it to the foreground to check it at anytime with:
{{code|fg 1}}
1 being the first task in the background.
====Restart Greyhole====
From the HDA: <br />
Setup > Settings > Servers > Greyhole <br />
Ensure Greyhole is started and the watchdog option is checked.
====Add Drives to Greyhole====
From the HDA:<br / >
Shares > Storage Pool > Check the drives (should be listed under the new mount points)<br / >
If your old mount points are still checked, uncheck them.
====Remove invalid symlinks====
{{code|sudo greyhole --fix-symlinks}}
At this point all of your files that were located on a drive whose mount point was changed will disappear from your shares. <br />
This is because the symlinks were no longer valid and greyhole is still looking for them in their old folders.<br />
Bring up the log and watch it work away at removing all those symlinks.<br />
Wait until it has completed.
====Delete Orphaned Metadata====
{{code|sudo greyhole --fsck --delete-orphaned-metadata}}
This will remove any metadata still stored for those missing files. It is necessary for the next step to work.
====Find the Orphaned Files====
{{code|sudo greyhole --fsck --find-orphaned-files --dir<nowiki>=</nowiki>/var/hda/files/drives/bay2/gh}}
This will run an fsck on the drive mounted in /var/hda/files/drives/bay2 and look for files without metadata. <br />
Repeat this for each drive you have changed the mount points for.<br />
At this point, your files should begin reappearing in your shares. If not, try running another fsck:
{{code|sudo greyhole --fix-symlinks
sudo greyhole --fsck}}

Greyhole

2013-05-29T23:52:28Z

JoshTheBlack: /* Moving drives/data out of Greyhole */

[[Category:apps]]
<div style="border: 1px solid #A3B1BF; padding: .8em 1em; background-color: #E6F2FF; margin: 0px 1em;">
'''NEW:''' [https://github.com/gboudreau/Greyhole/wiki/MigrateFromWHS Widows Home Server Drive Extender Migration Guide]

'''NEW:''' [[Greyhole troubleshooting]] guide
</div>

== What is Greyhole ==

[http://www.greyhole.net/ Greyhole] is Amahi's [[Storage pooling]] technology. Storage Pooling combines the space of multiple disk drives and makes them look as if they were all part of a single pool of disk space.
Specifically, Greyhole:
* Combines the space from multiple drives into a single volume
* Distributes files across all drives in the pool
* Creates multiple copies of files in admin-specified shares

This feature is installed by default, but requires a few simple steps to begin utilizing the features.

You can add additional drives to your hda and prepare them for use in Greyhole by following [[Adding a second hard drive to your HDA|this tutorial]].

To add a drive to your Greyhole storage pool. Open your HDA dashboard and navigate to the Shares tab. Then click on the Storage Pool sub-category. You will see a page similar to the one below.

== Important Warnings ==
<div style="color:darkred">You should '''never''' change or delete files in the shared directories (''/var/hda/files/*'' by default) directly on the HDA, using the terminal, or the Gnome file browser, for the shares for which you checked the ''Uses pool'' option in the Amahi dashboard. If you want to work with files on Greyhole shares on the HDA, you should [[Mount Shares Locally]].<br/>
You should be safe reading existing files directly, or adding new files directly, as long as don't care that your new files will only be moved into the storage pool during the next check, which runs automatically at midnight (or manually using ''greyhole --fsck''). Until then, your new files will be stored in your shared directories (normally ''/var/hda/files/share_name/'').

Also, touching anything inside the '''gh''' directories that Greyhole creates at the root of your partitions is a recipe for disaster.

We [[Greyhole not on root | strongly discourage you from using the root partition in a drive pool]].
</div><br/><br/>

== First things first ==

You need to go in the Settings tab, and enable '''Advanced Settings'''.<br/>
Without Advanced Settings enabled, you won't see the following page and options.

== For Storage Pool (Partitions) ==

[[File:Storage_Pool_1.png|600px|thumb|left]]

Select the drives you want available for your storage pool.

== Greyhole options ==

The next step is to select the share you want to replicate across the pool.

From the Shares tab, select the Shares sub-catagory. We chose the Pictures share for this tutorial.

[[File:Greyhole_Options_1.png|600px|thumb|left]]

Check the option for "Uses pool" and choose the number of drives to replicate this share. In this instance we have chosen to use all drives available to the greyhole pool.

Note: Greyhole is not a backup solution. If a file is removed, all copies are removed.

== Greyhole advanced options ==

You can further configure Greyhole by manually editing the following file:<br/>
'''/var/hda/platform/html/config/greyhole.yml'''

To see what options are available, and what they do, refer to the [https://gist.github.com/1379102 sample greyhole.conf] provided with Greyhole.

greyhole.yml is in in YAML format. Most of it should be easy enough to modify. The only exception would be the sticky_files (and optional sticky_into) options.<br/>
Here's an example of how those should appear:

To specify the following to Greyhole in greyhole.conf:

{{Text|Text=sticky_files <nowiki>=</nowiki> Music/
sticky_files <nowiki>=</nowiki> Videos/Movies/
stick_into <nowiki>=</nowiki> /mnt/hdd1/gh
stick_into <nowiki>=</nowiki> /mnt/hdd5/gh
sticky_files <nowiki>=</nowiki> Backups/CrashPlan/
stick_into <nowiki>=</nowiki> /mnt/hdd0/gh}}

one should specify this in the greyhole.yml file, where '''precise indentation matters''':

{{Text|Text=sticky_files:
- - Music/
- - Videos/Movies/
- - /mnt/hdd1/gh
- /mnt/hdd5/gh
- - Backups/CrashPlan/
- - /mnt/hdd0/gh}}

For your changes to be effective, you'll need to force Amahi to regenerate the greyhole.conf file. You can do so by editing a share, clicking it's path, and just clicking the Save button without actually changing the path.

== Copying data into shares for the first time ==

When you start using Greyhole, you might want to copy or move all your existing files into your new shares that use the storage pool.

Note: This is not necessary if your files are already in Amahi shares. If they are there, and you enable the ''Uses pool'' option in the Amahi dashboard, the files will start getting moved around into the drives in your storage pool during the night (starting at midnight), when the nightly storage pool check starts.<br/>
The instructions below are for users who have more data to copy into the Greyhole shares than their currently free space in the /var/hda/files/ folder.

One way to do that is to mount the shares that use the Greyhole storage pool, either on the HDA itself, or on a client computer on your local network, and copy your data from their existing location into the mounted shares.
This can be time consuming, but it is the safest way to use Greyhole.

Another way to move your files from their current location into the storage pool is to share their current location using an Amahi share that ''Uses pool'', then let Greyhole's nightly check move the files from there into the pool.

Here's a more detailed walkthrough for this method:

# Setup the Greyhole Storage Pool in the Amahi dashboard, Shares > Storage Pool page.
# Go in the Shares > Shares page. In there, make sure you have an existing share for each share you have data for. Create new ones if you need, remove the ones you don't need.
# Edit the ''path'' of each of those shares, and enter the current location of your existing data. For example, the Movies share could have a path = ''/media/External Drive/Movies''
# Enable the ''Uses pool'' option for each of your shares, and select the number of extra copies you'd like, if any.
# Now, you either need to wait for Greyhole's nightly check to start, or you can start it manually from a terminal, as root, using this command: greyhole --fsck
# Monitor /var/log/greyhole.log to see when the ''fsck'' operation is done.
# Once ''fsck'' is done, your data has now been moved into the Greyhole storage pool (in the drives you selected in Shares > Storage Pool). All that should be left in the previous location of your data (''/media/External Drive/Movies'' from the previous example) should be symbolic links pointing to the new file copies. If the previous location is just empty directories (no symlinks), do not panic. This is normal if your previous location is an NTFS or FAT partition (drive).
# Move all those directories / symlinks from there into the correct folders in /var/hda/files/share_name
# Back in the Amahi dashboard, edit the path of the shares once again, and put back ''/var/hda/files/share_name'' (i.e. the folders where you moved the symbolic links).
# If you used an NTFS or FAT partition for the previous location, you'll need another fsck to create the symlinks where they should be. Either wait for midnight, or launch it manually, from a command line, as root: ''greyhole --fsck''

You're done. All your existing data is now stored in the various drives included in your storage pool, and are accessible via the Samba shares you have defined in the Amahi dashboard.

== Adding a new drive to your HDA and storage pool ==
This wiki page discusses [[Adding_a_second_hard_drive_to_your_HDA|how to add a new drive to your HDA and to your greyhole storage pool.]]

== Drive Mounted as /media ==
Including any drive mounted as /media/Something in your storage pool is usually a bad idea.<br/>
Those mounts are created by the ''gnome-automounter'', which requires you to be logged in into X (Gnome) to become available.<br/>
This will create issues with Greyhole, which expects drives to always be available, and will take action when some of them are missing.

Follow this guide to [[Adding a second hard drive to your HDA|permanently mount your drives]], before you include them in your storage pool.

== Monitoring Greyhole ==
Sometimes you might want to monitor what Greyhole is doing, for example when writing data to your greyhole shares for the first time. Here are a few commands you can type in a terminal to follow along.

'''Scrolling view of total Greyhole operations queue:'''
{{Code|while [ 1 <nowiki>==</nowiki> 1 ]; do greyhole --view-queue <nowiki>|</nowiki> grep Total; sleep 60; done}}

'''Alternate way to watch Greyhole operations queue:'''
{{Code| watch -d greyhole --view-queue }}

'''Scrolling log of what files Greyhole is working on right now:'''
{{Code|tail -f /var/log/greyhole.log}}

'''Amahi App for watching the greyhole log in your web browser:'''

http://www.amahi.org/apps/greyhole-logmon

== Convert Greyhole from SQLite to MySQL ==
Greyhole is already using MySQL in Amahi 6.0

Greyhole was previously using SQLite as the default database for queueing up tasks on Amahi. This was unique to Amahi as Greyhole was originally designed to use MySQL for this task.

There are some major performance benefits to using MySQL over SQLite when writing large amounts of files. Switching can be especially useful when moving data to Greyhole shares for the first time. For now there is a script you can run if you want to switch over. This script has been tested to be safe while Greyhole is working but should be used with discretion.

''To Convert to MySQL, run as root:''

{{Code|/usr/share/greyhole/db_migration-sqlite2mysql.sh}}

To see what DB engine is Greyhole using, do this:

{{Code|grep db_engine /etc/greyhole.conf}}

== Disable Greyhole ==
For those who do not use Greyhole, you can disable it. This is based on the fact you never have used it by enabling 'Uses pool' on any share. Recommend using extreme caution as this could have unpredictable results.

Perform the following steps as user '''root''':

{{Code|chkconfig greyhole off
rm /etc/monit.d/greyhole.conf
service monit restart
service greyhole stop}}

'''DO NOT''' attempt to remove the Greyhole package as it is a dependency of the HDA software. Doing so will break your HDA.

= Testing and Reliability =

Check out the [[Greyhole grinder]] to help make Greyhole rock solid.

= Reconnect the Greyhole storage pool =

If you upgrade and/or reinstall Amahi and need to get your drives with data on them to the new system, follow this [[Reconnect_existing_Greyhole_storage pool]] guide.

= Greyhole Troubleshooting =

Page: [[Greyhole troubleshooting]]

= Landing Zone Considerations =

The landing zone or LZ is the area where files arrive first before being distributed to their final destination. See details in the [[Greyhole landing zone]] page.

= Manually updating Greyhole for Amahi =
Page: [[Greyhole updating]]

= Emptying Greyhole Attic =
{{Code|greyhole --empty-attic}}
About the attic: The attic is used like a Recycle Bin, or Trash.
That means you'll need to manually empty it once in a while.
To do so, use the --empty-attic parameter (see above).
Another option is to create a 'Greyhole Attic' Samba share.
More details about that here: https://github.com/gboudreau/Greyhole/wiki/AboutTrash

= Moving drives/data out of Greyhole =
You may need to remove a drive from Greyhole and transfer the share files to another drive: [[Greyhole moving data out of the pool]]

= Changing the Mount Points of your Greyhole drives =
[[Changing Greyhole Mount Points]]

= Reference =
Good [http://revxatlarge.blogspot.com/2011/04/restoring-deleted-files-in-greyhole-and.html article] on Greyhole with terms explained.

Greyhole

2013-05-29T23:50:48Z

JoshTheBlack: /* Monitoring Greyhole */

[[Category:apps]]
<div style="border: 1px solid #A3B1BF; padding: .8em 1em; background-color: #E6F2FF; margin: 0px 1em;">
'''NEW:''' [https://github.com/gboudreau/Greyhole/wiki/MigrateFromWHS Widows Home Server Drive Extender Migration Guide]

'''NEW:''' [[Greyhole troubleshooting]] guide
</div>

== What is Greyhole ==

[http://www.greyhole.net/ Greyhole] is Amahi's [[Storage pooling]] technology. Storage Pooling combines the space of multiple disk drives and makes them look as if they were all part of a single pool of disk space.
Specifically, Greyhole:
* Combines the space from multiple drives into a single volume
* Distributes files across all drives in the pool
* Creates multiple copies of files in admin-specified shares

This feature is installed by default, but requires a few simple steps to begin utilizing the features.

You can add additional drives to your hda and prepare them for use in Greyhole by following [[Adding a second hard drive to your HDA|this tutorial]].

To add a drive to your Greyhole storage pool. Open your HDA dashboard and navigate to the Shares tab. Then click on the Storage Pool sub-category. You will see a page similar to the one below.

== Important Warnings ==
<div style="color:darkred">You should '''never''' change or delete files in the shared directories (''/var/hda/files/*'' by default) directly on the HDA, using the terminal, or the Gnome file browser, for the shares for which you checked the ''Uses pool'' option in the Amahi dashboard. If you want to work with files on Greyhole shares on the HDA, you should [[Mount Shares Locally]].<br/>
You should be safe reading existing files directly, or adding new files directly, as long as don't care that your new files will only be moved into the storage pool during the next check, which runs automatically at midnight (or manually using ''greyhole --fsck''). Until then, your new files will be stored in your shared directories (normally ''/var/hda/files/share_name/'').

Also, touching anything inside the '''gh''' directories that Greyhole creates at the root of your partitions is a recipe for disaster.

We [[Greyhole not on root | strongly discourage you from using the root partition in a drive pool]].
</div><br/><br/>

== First things first ==

You need to go in the Settings tab, and enable '''Advanced Settings'''.<br/>
Without Advanced Settings enabled, you won't see the following page and options.

== For Storage Pool (Partitions) ==

[[File:Storage_Pool_1.png|600px|thumb|left]]

Select the drives you want available for your storage pool.

== Greyhole options ==

The next step is to select the share you want to replicate across the pool.

From the Shares tab, select the Shares sub-catagory. We chose the Pictures share for this tutorial.

[[File:Greyhole_Options_1.png|600px|thumb|left]]

Check the option for "Uses pool" and choose the number of drives to replicate this share. In this instance we have chosen to use all drives available to the greyhole pool.

Note: Greyhole is not a backup solution. If a file is removed, all copies are removed.

== Greyhole advanced options ==

You can further configure Greyhole by manually editing the following file:<br/>
'''/var/hda/platform/html/config/greyhole.yml'''

To see what options are available, and what they do, refer to the [https://gist.github.com/1379102 sample greyhole.conf] provided with Greyhole.

greyhole.yml is in in YAML format. Most of it should be easy enough to modify. The only exception would be the sticky_files (and optional sticky_into) options.<br/>
Here's an example of how those should appear:

To specify the following to Greyhole in greyhole.conf:

{{Text|Text=sticky_files <nowiki>=</nowiki> Music/
sticky_files <nowiki>=</nowiki> Videos/Movies/
stick_into <nowiki>=</nowiki> /mnt/hdd1/gh
stick_into <nowiki>=</nowiki> /mnt/hdd5/gh
sticky_files <nowiki>=</nowiki> Backups/CrashPlan/
stick_into <nowiki>=</nowiki> /mnt/hdd0/gh}}

one should specify this in the greyhole.yml file, where '''precise indentation matters''':

{{Text|Text=sticky_files:
- - Music/
- - Videos/Movies/
- - /mnt/hdd1/gh
- /mnt/hdd5/gh
- - Backups/CrashPlan/
- - /mnt/hdd0/gh}}

For your changes to be effective, you'll need to force Amahi to regenerate the greyhole.conf file. You can do so by editing a share, clicking it's path, and just clicking the Save button without actually changing the path.

== Copying data into shares for the first time ==

When you start using Greyhole, you might want to copy or move all your existing files into your new shares that use the storage pool.

Note: This is not necessary if your files are already in Amahi shares. If they are there, and you enable the ''Uses pool'' option in the Amahi dashboard, the files will start getting moved around into the drives in your storage pool during the night (starting at midnight), when the nightly storage pool check starts.<br/>
The instructions below are for users who have more data to copy into the Greyhole shares than their currently free space in the /var/hda/files/ folder.

One way to do that is to mount the shares that use the Greyhole storage pool, either on the HDA itself, or on a client computer on your local network, and copy your data from their existing location into the mounted shares.
This can be time consuming, but it is the safest way to use Greyhole.

Another way to move your files from their current location into the storage pool is to share their current location using an Amahi share that ''Uses pool'', then let Greyhole's nightly check move the files from there into the pool.

Here's a more detailed walkthrough for this method:

# Setup the Greyhole Storage Pool in the Amahi dashboard, Shares > Storage Pool page.
# Go in the Shares > Shares page. In there, make sure you have an existing share for each share you have data for. Create new ones if you need, remove the ones you don't need.
# Edit the ''path'' of each of those shares, and enter the current location of your existing data. For example, the Movies share could have a path = ''/media/External Drive/Movies''
# Enable the ''Uses pool'' option for each of your shares, and select the number of extra copies you'd like, if any.
# Now, you either need to wait for Greyhole's nightly check to start, or you can start it manually from a terminal, as root, using this command: greyhole --fsck
# Monitor /var/log/greyhole.log to see when the ''fsck'' operation is done.
# Once ''fsck'' is done, your data has now been moved into the Greyhole storage pool (in the drives you selected in Shares > Storage Pool). All that should be left in the previous location of your data (''/media/External Drive/Movies'' from the previous example) should be symbolic links pointing to the new file copies. If the previous location is just empty directories (no symlinks), do not panic. This is normal if your previous location is an NTFS or FAT partition (drive).
# Move all those directories / symlinks from there into the correct folders in /var/hda/files/share_name
# Back in the Amahi dashboard, edit the path of the shares once again, and put back ''/var/hda/files/share_name'' (i.e. the folders where you moved the symbolic links).
# If you used an NTFS or FAT partition for the previous location, you'll need another fsck to create the symlinks where they should be. Either wait for midnight, or launch it manually, from a command line, as root: ''greyhole --fsck''

You're done. All your existing data is now stored in the various drives included in your storage pool, and are accessible via the Samba shares you have defined in the Amahi dashboard.

== Adding a new drive to your HDA and storage pool ==
This wiki page discusses [[Adding_a_second_hard_drive_to_your_HDA|how to add a new drive to your HDA and to your greyhole storage pool.]]

== Drive Mounted as /media ==
Including any drive mounted as /media/Something in your storage pool is usually a bad idea.<br/>
Those mounts are created by the ''gnome-automounter'', which requires you to be logged in into X (Gnome) to become available.<br/>
This will create issues with Greyhole, which expects drives to always be available, and will take action when some of them are missing.

Follow this guide to [[Adding a second hard drive to your HDA|permanently mount your drives]], before you include them in your storage pool.

== Monitoring Greyhole ==
Sometimes you might want to monitor what Greyhole is doing, for example when writing data to your greyhole shares for the first time. Here are a few commands you can type in a terminal to follow along.

'''Scrolling view of total Greyhole operations queue:'''
{{Code|while [ 1 <nowiki>==</nowiki> 1 ]; do greyhole --view-queue <nowiki>|</nowiki> grep Total; sleep 60; done}}

'''Alternate way to watch Greyhole operations queue:'''
{{Code| watch -d greyhole --view-queue }}

'''Scrolling log of what files Greyhole is working on right now:'''
{{Code|tail -f /var/log/greyhole.log}}

'''Amahi App for watching the greyhole log in your web browser:'''

http://www.amahi.org/apps/greyhole-logmon

== Convert Greyhole from SQLite to MySQL ==
Greyhole is already using MySQL in Amahi 6.0

Greyhole was previously using SQLite as the default database for queueing up tasks on Amahi. This was unique to Amahi as Greyhole was originally designed to use MySQL for this task.

There are some major performance benefits to using MySQL over SQLite when writing large amounts of files. Switching can be especially useful when moving data to Greyhole shares for the first time. For now there is a script you can run if you want to switch over. This script has been tested to be safe while Greyhole is working but should be used with discretion.

''To Convert to MySQL, run as root:''

{{Code|/usr/share/greyhole/db_migration-sqlite2mysql.sh}}

To see what DB engine is Greyhole using, do this:

{{Code|grep db_engine /etc/greyhole.conf}}

== Disable Greyhole ==
For those who do not use Greyhole, you can disable it. This is based on the fact you never have used it by enabling 'Uses pool' on any share. Recommend using extreme caution as this could have unpredictable results.

Perform the following steps as user '''root''':

{{Code|chkconfig greyhole off
rm /etc/monit.d/greyhole.conf
service monit restart
service greyhole stop}}

'''DO NOT''' attempt to remove the Greyhole package as it is a dependency of the HDA software. Doing so will break your HDA.

= Testing and Reliability =

Check out the [[Greyhole grinder]] to help make Greyhole rock solid.

= Reconnect the Greyhole storage pool =

If you upgrade and/or reinstall Amahi and need to get your drives with data on them to the new system, follow this [[Reconnect_existing_Greyhole_storage pool]] guide.

= Greyhole Troubleshooting =

Page: [[Greyhole troubleshooting]]

= Landing Zone Considerations =

The landing zone or LZ is the area where files arrive first before being distributed to their final destination. See details in the [[Greyhole landing zone]] page.

= Manually updating Greyhole for Amahi =
Page: [[Greyhole updating]]

= Emptying Greyhole Attic =
{{Code|greyhole --empty-attic}}
About the attic: The attic is used like a Recycle Bin, or Trash.
That means you'll need to manually empty it once in a while.
To do so, use the --empty-attic parameter (see above).
Another option is to create a 'Greyhole Attic' Samba share.
More details about that here: https://github.com/gboudreau/Greyhole/wiki/AboutTrash

= Moving drives/data out of Greyhole =
You may need to remove a drive from Greyhole and transfer the share files to another drive: [[Greyhole moving data out of the pool]]

= Reference =
Good [http://revxatlarge.blogspot.com/2011/04/restoring-deleted-files-in-greyhole-and.html article] on Greyhole with terms explained.

Greyhole

2013-05-29T23:48:36Z

JoshTheBlack: /* Monitoring Greyhole */

[[Category:apps]]
<div style="border: 1px solid #A3B1BF; padding: .8em 1em; background-color: #E6F2FF; margin: 0px 1em;">
'''NEW:''' [https://github.com/gboudreau/Greyhole/wiki/MigrateFromWHS Widows Home Server Drive Extender Migration Guide]

'''NEW:''' [[Greyhole troubleshooting]] guide
</div>

== What is Greyhole ==

[http://www.greyhole.net/ Greyhole] is Amahi's [[Storage pooling]] technology. Storage Pooling combines the space of multiple disk drives and makes them look as if they were all part of a single pool of disk space.
Specifically, Greyhole:
* Combines the space from multiple drives into a single volume
* Distributes files across all drives in the pool
* Creates multiple copies of files in admin-specified shares

This feature is installed by default, but requires a few simple steps to begin utilizing the features.

You can add additional drives to your hda and prepare them for use in Greyhole by following [[Adding a second hard drive to your HDA|this tutorial]].

To add a drive to your Greyhole storage pool. Open your HDA dashboard and navigate to the Shares tab. Then click on the Storage Pool sub-category. You will see a page similar to the one below.

== Important Warnings ==
<div style="color:darkred">You should '''never''' change or delete files in the shared directories (''/var/hda/files/*'' by default) directly on the HDA, using the terminal, or the Gnome file browser, for the shares for which you checked the ''Uses pool'' option in the Amahi dashboard. If you want to work with files on Greyhole shares on the HDA, you should [[Mount Shares Locally]].<br/>
You should be safe reading existing files directly, or adding new files directly, as long as don't care that your new files will only be moved into the storage pool during the next check, which runs automatically at midnight (or manually using ''greyhole --fsck''). Until then, your new files will be stored in your shared directories (normally ''/var/hda/files/share_name/'').

Also, touching anything inside the '''gh''' directories that Greyhole creates at the root of your partitions is a recipe for disaster.

We [[Greyhole not on root | strongly discourage you from using the root partition in a drive pool]].
</div><br/><br/>

== First things first ==

You need to go in the Settings tab, and enable '''Advanced Settings'''.<br/>
Without Advanced Settings enabled, you won't see the following page and options.

== For Storage Pool (Partitions) ==

[[File:Storage_Pool_1.png|600px|thumb|left]]

Select the drives you want available for your storage pool.

== Greyhole options ==

The next step is to select the share you want to replicate across the pool.

From the Shares tab, select the Shares sub-catagory. We chose the Pictures share for this tutorial.

[[File:Greyhole_Options_1.png|600px|thumb|left]]

Check the option for "Uses pool" and choose the number of drives to replicate this share. In this instance we have chosen to use all drives available to the greyhole pool.

Note: Greyhole is not a backup solution. If a file is removed, all copies are removed.

== Greyhole advanced options ==

You can further configure Greyhole by manually editing the following file:<br/>
'''/var/hda/platform/html/config/greyhole.yml'''

To see what options are available, and what they do, refer to the [https://gist.github.com/1379102 sample greyhole.conf] provided with Greyhole.

greyhole.yml is in in YAML format. Most of it should be easy enough to modify. The only exception would be the sticky_files (and optional sticky_into) options.<br/>
Here's an example of how those should appear:

To specify the following to Greyhole in greyhole.conf:

{{Text|Text=sticky_files <nowiki>=</nowiki> Music/
sticky_files <nowiki>=</nowiki> Videos/Movies/
stick_into <nowiki>=</nowiki> /mnt/hdd1/gh
stick_into <nowiki>=</nowiki> /mnt/hdd5/gh
sticky_files <nowiki>=</nowiki> Backups/CrashPlan/
stick_into <nowiki>=</nowiki> /mnt/hdd0/gh}}

one should specify this in the greyhole.yml file, where '''precise indentation matters''':

{{Text|Text=sticky_files:
- - Music/
- - Videos/Movies/
- - /mnt/hdd1/gh
- /mnt/hdd5/gh
- - Backups/CrashPlan/
- - /mnt/hdd0/gh}}

For your changes to be effective, you'll need to force Amahi to regenerate the greyhole.conf file. You can do so by editing a share, clicking it's path, and just clicking the Save button without actually changing the path.

== Copying data into shares for the first time ==

When you start using Greyhole, you might want to copy or move all your existing files into your new shares that use the storage pool.

Note: This is not necessary if your files are already in Amahi shares. If they are there, and you enable the ''Uses pool'' option in the Amahi dashboard, the files will start getting moved around into the drives in your storage pool during the night (starting at midnight), when the nightly storage pool check starts.<br/>
The instructions below are for users who have more data to copy into the Greyhole shares than their currently free space in the /var/hda/files/ folder.

One way to do that is to mount the shares that use the Greyhole storage pool, either on the HDA itself, or on a client computer on your local network, and copy your data from their existing location into the mounted shares.
This can be time consuming, but it is the safest way to use Greyhole.

Another way to move your files from their current location into the storage pool is to share their current location using an Amahi share that ''Uses pool'', then let Greyhole's nightly check move the files from there into the pool.

Here's a more detailed walkthrough for this method:

# Setup the Greyhole Storage Pool in the Amahi dashboard, Shares > Storage Pool page.
# Go in the Shares > Shares page. In there, make sure you have an existing share for each share you have data for. Create new ones if you need, remove the ones you don't need.
# Edit the ''path'' of each of those shares, and enter the current location of your existing data. For example, the Movies share could have a path = ''/media/External Drive/Movies''
# Enable the ''Uses pool'' option for each of your shares, and select the number of extra copies you'd like, if any.
# Now, you either need to wait for Greyhole's nightly check to start, or you can start it manually from a terminal, as root, using this command: greyhole --fsck
# Monitor /var/log/greyhole.log to see when the ''fsck'' operation is done.
# Once ''fsck'' is done, your data has now been moved into the Greyhole storage pool (in the drives you selected in Shares > Storage Pool). All that should be left in the previous location of your data (''/media/External Drive/Movies'' from the previous example) should be symbolic links pointing to the new file copies. If the previous location is just empty directories (no symlinks), do not panic. This is normal if your previous location is an NTFS or FAT partition (drive).
# Move all those directories / symlinks from there into the correct folders in /var/hda/files/share_name
# Back in the Amahi dashboard, edit the path of the shares once again, and put back ''/var/hda/files/share_name'' (i.e. the folders where you moved the symbolic links).
# If you used an NTFS or FAT partition for the previous location, you'll need another fsck to create the symlinks where they should be. Either wait for midnight, or launch it manually, from a command line, as root: ''greyhole --fsck''

You're done. All your existing data is now stored in the various drives included in your storage pool, and are accessible via the Samba shares you have defined in the Amahi dashboard.

== Adding a new drive to your HDA and storage pool ==
This wiki page discusses [[Adding_a_second_hard_drive_to_your_HDA|how to add a new drive to your HDA and to your greyhole storage pool.]]

== Drive Mounted as /media ==
Including any drive mounted as /media/Something in your storage pool is usually a bad idea.<br/>
Those mounts are created by the ''gnome-automounter'', which requires you to be logged in into X (Gnome) to become available.<br/>
This will create issues with Greyhole, which expects drives to always be available, and will take action when some of them are missing.

Follow this guide to [[Adding a second hard drive to your HDA|permanently mount your drives]], before you include them in your storage pool.

== Monitoring Greyhole ==
Sometimes you might want to monitor what Greyhole is doing, for example when writing data to your greyhole shares for the first time. Here are a few commands you can type in a terminal to follow along.

'''Scrolling view of total Greyhole operations queue:'''
{{Code|while [ 1 <nowiki>==</nowiki> 1 ]; do greyhole --view-queue <nowiki>|</nowiki> grep Total; sleep 60; done}}

'''Alternate way to watch Greyhole operations queue:'''
{{Code| watch -d greyhole --view-queue }}

'''Scrolling log of what files Greyhole is working on right now:'''
{{Code|tail -f /var/log/greyhole.log}}

'''Amahi App for watching the greyhole log in your web browser'''
http://www.amahi.org/apps/greyhole-logmon

== Convert Greyhole from SQLite to MySQL ==
Greyhole is already using MySQL in Amahi 6.0

Greyhole was previously using SQLite as the default database for queueing up tasks on Amahi. This was unique to Amahi as Greyhole was originally designed to use MySQL for this task.

There are some major performance benefits to using MySQL over SQLite when writing large amounts of files. Switching can be especially useful when moving data to Greyhole shares for the first time. For now there is a script you can run if you want to switch over. This script has been tested to be safe while Greyhole is working but should be used with discretion.

''To Convert to MySQL, run as root:''

{{Code|/usr/share/greyhole/db_migration-sqlite2mysql.sh}}

To see what DB engine is Greyhole using, do this:

{{Code|grep db_engine /etc/greyhole.conf}}

== Disable Greyhole ==
For those who do not use Greyhole, you can disable it. This is based on the fact you never have used it by enabling 'Uses pool' on any share. Recommend using extreme caution as this could have unpredictable results.

Perform the following steps as user '''root''':

{{Code|chkconfig greyhole off
rm /etc/monit.d/greyhole.conf
service monit restart
service greyhole stop}}

'''DO NOT''' attempt to remove the Greyhole package as it is a dependency of the HDA software. Doing so will break your HDA.

= Testing and Reliability =

Check out the [[Greyhole grinder]] to help make Greyhole rock solid.

= Reconnect the Greyhole storage pool =

If you upgrade and/or reinstall Amahi and need to get your drives with data on them to the new system, follow this [[Reconnect_existing_Greyhole_storage pool]] guide.

= Greyhole Troubleshooting =

Page: [[Greyhole troubleshooting]]

= Landing Zone Considerations =

The landing zone or LZ is the area where files arrive first before being distributed to their final destination. See details in the [[Greyhole landing zone]] page.

= Manually updating Greyhole for Amahi =
Page: [[Greyhole updating]]

= Emptying Greyhole Attic =
{{Code|greyhole --empty-attic}}
About the attic: The attic is used like a Recycle Bin, or Trash.
That means you'll need to manually empty it once in a while.
To do so, use the --empty-attic parameter (see above).
Another option is to create a 'Greyhole Attic' Samba share.
More details about that here: https://github.com/gboudreau/Greyhole/wiki/AboutTrash

= Moving drives/data out of Greyhole =
You may need to remove a drive from Greyhole and transfer the share files to another drive: [[Greyhole moving data out of the pool]]

= Reference =
Good [http://revxatlarge.blogspot.com/2011/04/restoring-deleted-files-in-greyhole-and.html article] on Greyhole with terms explained.

Talk:Partitions Over 2.1 TB

2013-05-29T23:46:28Z

JoshTheBlack:

2013.05.29: Removed the whole bit about editing the hda-diskmount script / manually mounting drive because the hda-diskmount script has supported GPT partitions since early 2012.

Talk:Partitions Over 2.1 TB

2013-05-29T23:46:06Z

JoshTheBlack: Created page with "Removed the whole bit about editing the hda-diskmount script / manually mounting drive because the hda-diskmount script has supported GPT partitions since early 2012."

Removed the whole bit about editing the hda-diskmount script / manually mounting drive because the hda-diskmount script has supported GPT partitions since early 2012.

Partitions Over 2.1 TB

2013-05-29T23:43:37Z

JoshTheBlack: /* Format the drive! */

Partitions Over 2.1 TB

2013-05-29T23:43:15Z

JoshTheBlack: /* Adding the drive to your HDA */

Partitions Over 2.1 TB

2013-05-29T23:38:51Z

JoshTheBlack: /* Alternative Parted usage */

=Foreward=
You cannot use a >=2.1TB partition as your boot device unless you have a UEFI bios. That is beyond the scope of this article.

When using a >=2.1TB partition, you should be running 64-bit Amahi.

Before you use a >=2.1TB drive on Windows, please read this support article: http://support.microsoft.com/kb/2581408

=Introduction=
As hard drives have increased in capacity over time, some clever workarounds have been engineered to keep breaking barriers, such as the move from CHS to LBA. Unfortunately, with older style MBR partitions, there is a limit of 2.1TB that simply cannot be worked around using an MBR partition. We have to instead use newer GPT style partitions.

I'm not going to delve into the history too much, you can google/wikipedia it yourself if you like.

So, if you've just purchased a snazzy new 3TB drive like a Western Digital Caviar Green, and you're scratching your head as to why you can't get the full capacity, here's the fix.

=Assumptions=
The below documentation assumes you have an existing boot drive with Amahi, namely /dev/sda. Your >2.1TB HDD will be /dev/sdb

The instructions also assume a Linux terminal, such as that on your Amahi box (either using its console, the Terminal application within the GUI, or SSH'd in)

=Warning=
BE ABSOLUTELY SURE THAT YOU ARE RUNNING THESE COMMANDS AGAINST THE CORRECT DRIVE. WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS, HARDWARE MALFUNCTION, ETC!

=OK, Let's do it=
First we label the drive with a GPT partition
{{Code|
parted /dev/sdb mklabel gpt
}}

Now we select sectors as a unit of measurement
{{Code|
parted /dev/sdb unit s
}}

Now we make the partition.
{{Code|
parted /dev/sdb mkpart primary ext4 2048 -1
}}
Parted may complain about the last sector and will automatically suggest a correct sector, just say Yes to the prompt.

We make it as a primary partition, ext4 filesystem, and we carefully select the sectors. The first number MUST be divisible by 8, so you can try 40, 48, 56, 64 etc... For me these numbers threw up errors, so I just went to 2048 and everything worked fine, and in the grand scheme of a 3TB drive, the extra sectors don't really matter :)

The reason that the starting sector is divisible by 8 is for aligning the sectors. This is because HDD's have traditionally been based around 512-byte sectors, yet newer, higher capacity HDD's are now arriving based around 4096-byte (a.k.a. 4k) sectors. The partitioning will still work with 512-bytes, but the drive's performance will be drastically impacted - in some testing it can be twice as slow, in others up to 25 times slower, depending on the sector alignment. So it's important to get this right!!!

=Alternative Parted usage=
Instead of the sequence of one liners up there, you can enter into parted itself like this. I give this as I don't know how your version of parted is going to behave. The interactive stuff from parted has been removed:
{{Code|
parted /dev/sdb
(parted) mklabel gpt
(parted) unit s
(parted) mkpart primary ext4 2048 -1
(parted) quit
}}

=Format the drive!=
Finally, let's get that drive formatted to a nice ext4 volume:
{{Code|
mkfs.ext4 -T largefile4 /dev/sdb1
}}

=Adding the drive to your HDA=
Normally to add a drive to Amahi, you would run the script '''hda-diskmount''', which searches for any unmounted drives and mounts them. Unfortunately, this script doesn't yet cater for GPT partitions. It runs an '''fdisk -l''' and searches out drives with a Linux system type, and with what it finds it mounts any that aren't mounted.

If we run '''fdisk -l''' by itself, we will see that our new drive doesn't return a system type of 'Linux', instead it returns 'GPT' as well as a warning:

{{Code|
Code= WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
}}

So hda-diskmount correctly ignores the drive. You can either [http://forums.amahi.org/viewtopic.php?f=15&t=2326 fix hda-diskmount], or you can manually mount the drives with the instructions below.

First we make our mount point

{{Code|
mkdir /var/hda/files/drives/sdb1
}}

Next we exercise good practice and backup our fstab file, I like to use `date +%Y%m%d` to give the name a date stamp e.g. /etc/fstab.20110731 represents a backup done on the 31st of July, 2011. This isn't necessary, you could just use something like 'fstab.old', but date-stamping your file backups is a good habit to get into
{{Code|
Code= cp /etc/fstab /etc/fstab.`date +%Y%m%d`
}}

Now we adjust the fstab file

{{Code|
Code= echo -e /dev/sdb1$'\t\t'/var/hda/files/drives/sdb1$'\t'ext4$'\t'defaults$'\t'1 1 >> /etc/fstab
}}

What this does is adds a line to the /etc/fstab file, telling it that when Amahi boots, it has to mount the drive. The $'\t' entries simply mean 'put in a tab space'

If you now run '''cat /etc/fstab''' you should see a nice entry at the bottom, similar to this

{{Code|
Code= cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Jul 28 23:56:48 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_hda-LogVol01 / ext4 defaults 1 1
UUID=cc1204dd-a4f8-42f8-8736-b5970251a865 /boot ext4 defaults 1 2
/dev/mapper/vg_hda-LogVol00 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sdb1 /var/hda/files/drives/sdb1 ext4 defaults 1 1
}}

Now you can either reboot to allow the fstab file to mount your new drive, or you can simply run '''mount -a'''

Now if you run mount by itself, you should see your drive listed e.g.

{{Code|
Code= mount
/dev/mapper/vg_hda-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdd1 on /media/520abb16-ac7c-4f65-9cc3-9e536c93dca2 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /var/hda/files/drives/sdb1 type ext4 (rw)
}}

=A note about Western Digital drives=
Western Digital make some nice hardware, but they are also incredibly stupid. Many of their hard drives will automatically park their heads every 8 seconds, which wears out the hard drives very quickly, in some cases the HDD's will reach their design limit (300k parks for consumer, 600k parks for enterprise) within 3-4 months!!! This isn't to say that the drives will necessarily die within 3-4 months, but it's still not good!

Fortunately we can fix this using a Western Digital tool named wdidle3. You can download it [http://support.wdc.com/product/download.asp?groupid=609&sid=113 here].

Create a bootable usb drive using [http://www.freedos.org/freedos/files/ FreeDOS] and [http://unetbootin.sourceforge.net/ unetbootin], then copy wdidle.exe onto the usb drive. Boot up your Amahi box to FreeDOS and enter the following commands:

{{Code|
c:\
wdidle3 /R
wdidle3 /S300
}}

This cd's you to the usb drive's root, then we run wdidle3 /R to display the current drive status, then we run wdidle3 /S300 to set the park time to 5 minutes. Alternatively you could run wdidle3 /D to completely disable the parking.

When you're done, simply restart the PC!

n.b. Unetbootin was a bit finnicky for me, I found that if I created the drive with a FreeDOS live CD that it wouldn't work, but if I then re-created using unetbootin's automatic distribution download feature, the USB stick worked a treat. YMMV.

Partitions Over 2.1 TB

2013-05-29T23:38:31Z

JoshTheBlack: /* OK, Let's do it */

=Foreward=
You cannot use a >=2.1TB partition as your boot device unless you have a UEFI bios. That is beyond the scope of this article.

When using a >=2.1TB partition, you should be running 64-bit Amahi.

Before you use a >=2.1TB drive on Windows, please read this support article: http://support.microsoft.com/kb/2581408

=Introduction=
As hard drives have increased in capacity over time, some clever workarounds have been engineered to keep breaking barriers, such as the move from CHS to LBA. Unfortunately, with older style MBR partitions, there is a limit of 2.1TB that simply cannot be worked around using an MBR partition. We have to instead use newer GPT style partitions.

I'm not going to delve into the history too much, you can google/wikipedia it yourself if you like.

So, if you've just purchased a snazzy new 3TB drive like a Western Digital Caviar Green, and you're scratching your head as to why you can't get the full capacity, here's the fix.

=Assumptions=
The below documentation assumes you have an existing boot drive with Amahi, namely /dev/sda. Your >2.1TB HDD will be /dev/sdb

The instructions also assume a Linux terminal, such as that on your Amahi box (either using its console, the Terminal application within the GUI, or SSH'd in)

=Warning=
BE ABSOLUTELY SURE THAT YOU ARE RUNNING THESE COMMANDS AGAINST THE CORRECT DRIVE. WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS, HARDWARE MALFUNCTION, ETC!

=OK, Let's do it=
First we label the drive with a GPT partition
{{Code|
parted /dev/sdb mklabel gpt
}}

Now we select sectors as a unit of measurement
{{Code|
parted /dev/sdb unit s
}}

Now we make the partition.
{{Code|
parted /dev/sdb mkpart primary ext4 2048 -1
}}
Parted may complain about the last sector and will automatically suggest a correct sector, just say Yes to the prompt.

We make it as a primary partition, ext4 filesystem, and we carefully select the sectors. The first number MUST be divisible by 8, so you can try 40, 48, 56, 64 etc... For me these numbers threw up errors, so I just went to 2048 and everything worked fine, and in the grand scheme of a 3TB drive, the extra sectors don't really matter :)

The reason that the starting sector is divisible by 8 is for aligning the sectors. This is because HDD's have traditionally been based around 512-byte sectors, yet newer, higher capacity HDD's are now arriving based around 4096-byte (a.k.a. 4k) sectors. The partitioning will still work with 512-bytes, but the drive's performance will be drastically impacted - in some testing it can be twice as slow, in others up to 25 times slower, depending on the sector alignment. So it's important to get this right!!!

=Alternative Parted usage=
Instead of the sequence of one liners up there, you can enter into parted itself like this. I give this as I don't know how your version of parted is going to behave. The interactive stuff from parted has been removed:
{{Code|
parted /dev/sdb
(parted) mklabel gpt
(parted) unit s
(parted) mkpart primary ext2 2048 -1
(parted) quit
}}

=Format the drive!=
Finally, let's get that drive formatted to a nice ext4 volume:
{{Code|
mkfs.ext4 -T largefile4 /dev/sdb1
}}

=Adding the drive to your HDA=
Normally to add a drive to Amahi, you would run the script '''hda-diskmount''', which searches for any unmounted drives and mounts them. Unfortunately, this script doesn't yet cater for GPT partitions. It runs an '''fdisk -l''' and searches out drives with a Linux system type, and with what it finds it mounts any that aren't mounted.

If we run '''fdisk -l''' by itself, we will see that our new drive doesn't return a system type of 'Linux', instead it returns 'GPT' as well as a warning:

{{Code|
Code= WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
}}

So hda-diskmount correctly ignores the drive. You can either [http://forums.amahi.org/viewtopic.php?f=15&t=2326 fix hda-diskmount], or you can manually mount the drives with the instructions below.

First we make our mount point

{{Code|
mkdir /var/hda/files/drives/sdb1
}}

Next we exercise good practice and backup our fstab file, I like to use `date +%Y%m%d` to give the name a date stamp e.g. /etc/fstab.20110731 represents a backup done on the 31st of July, 2011. This isn't necessary, you could just use something like 'fstab.old', but date-stamping your file backups is a good habit to get into
{{Code|
Code= cp /etc/fstab /etc/fstab.`date +%Y%m%d`
}}

Now we adjust the fstab file

{{Code|
Code= echo -e /dev/sdb1$'\t\t'/var/hda/files/drives/sdb1$'\t'ext4$'\t'defaults$'\t'1 1 >> /etc/fstab
}}

What this does is adds a line to the /etc/fstab file, telling it that when Amahi boots, it has to mount the drive. The $'\t' entries simply mean 'put in a tab space'

If you now run '''cat /etc/fstab''' you should see a nice entry at the bottom, similar to this

{{Code|
Code= cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Jul 28 23:56:48 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_hda-LogVol01 / ext4 defaults 1 1
UUID=cc1204dd-a4f8-42f8-8736-b5970251a865 /boot ext4 defaults 1 2
/dev/mapper/vg_hda-LogVol00 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sdb1 /var/hda/files/drives/sdb1 ext4 defaults 1 1
}}

Now you can either reboot to allow the fstab file to mount your new drive, or you can simply run '''mount -a'''

Now if you run mount by itself, you should see your drive listed e.g.

{{Code|
Code= mount
/dev/mapper/vg_hda-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdd1 on /media/520abb16-ac7c-4f65-9cc3-9e536c93dca2 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /var/hda/files/drives/sdb1 type ext4 (rw)
}}

=A note about Western Digital drives=
Western Digital make some nice hardware, but they are also incredibly stupid. Many of their hard drives will automatically park their heads every 8 seconds, which wears out the hard drives very quickly, in some cases the HDD's will reach their design limit (300k parks for consumer, 600k parks for enterprise) within 3-4 months!!! This isn't to say that the drives will necessarily die within 3-4 months, but it's still not good!

Fortunately we can fix this using a Western Digital tool named wdidle3. You can download it [http://support.wdc.com/product/download.asp?groupid=609&sid=113 here].

Create a bootable usb drive using [http://www.freedos.org/freedos/files/ FreeDOS] and [http://unetbootin.sourceforge.net/ unetbootin], then copy wdidle.exe onto the usb drive. Boot up your Amahi box to FreeDOS and enter the following commands:

{{Code|
c:\
wdidle3 /R
wdidle3 /S300
}}

This cd's you to the usb drive's root, then we run wdidle3 /R to display the current drive status, then we run wdidle3 /S300 to set the park time to 5 minutes. Alternatively you could run wdidle3 /D to completely disable the parking.

When you're done, simply restart the PC!

n.b. Unetbootin was a bit finnicky for me, I found that if I created the drive with a FreeDOS live CD that it wouldn't work, but if I then re-created using unetbootin's automatic distribution download feature, the USB stick worked a treat. YMMV.

Partitions Over 2.1 TB

2013-05-29T23:32:10Z

JoshTheBlack: /* Foreward */

=Foreward=
You cannot use a >=2.1TB partition as your boot device unless you have a UEFI bios. That is beyond the scope of this article.

When using a >=2.1TB partition, you should be running 64-bit Amahi.

Before you use a >=2.1TB drive on Windows, please read this support article: http://support.microsoft.com/kb/2581408

=Introduction=
As hard drives have increased in capacity over time, some clever workarounds have been engineered to keep breaking barriers, such as the move from CHS to LBA. Unfortunately, with older style MBR partitions, there is a limit of 2.1TB that simply cannot be worked around using an MBR partition. We have to instead use newer GPT style partitions.

I'm not going to delve into the history too much, you can google/wikipedia it yourself if you like.

So, if you've just purchased a snazzy new 3TB drive like a Western Digital Caviar Green, and you're scratching your head as to why you can't get the full capacity, here's the fix.

=Assumptions=
The below documentation assumes you have an existing boot drive with Amahi, namely /dev/sda. Your >2.1TB HDD will be /dev/sdb

The instructions also assume a Linux terminal, such as that on your Amahi box (either using its console, the Terminal application within the GUI, or SSH'd in)

=Warning=
BE ABSOLUTELY SURE THAT YOU ARE RUNNING THESE COMMANDS AGAINST THE CORRECT DRIVE. WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS, HARDWARE MALFUNCTION, ETC!

=OK, Let's do it=
First we label the drive with a GPT partition
{{Code|
parted /dev/sdb mklabel gpt
}}

Now we select sectors as a unit of measurement
{{Code|
parted /dev/sdb unit s
}}

Now we make the partition.
{{Code|
parted /dev/sdb mkpart primary ext2 2048 -1
}}
Parted may complain about the last sector and will automatically suggest a correct sector, just say Yes to the prompt.

We make it as a primary partition, ext2 filesystem, and we carefully select the sectors. The first number MUST be divisible by 8, so you can try 40, 48, 56, 64 etc... For me these numbers threw up errors, so I just went to 2048 and everything worked fine, and in the grand scheme of a 3TB drive, the extra sectors don't really matter :)

The reason that the starting sector is divisible by 8 is for aligning the sectors. This is because HDD's have traditionally been based around 512-byte sectors, yet newer, higher capacity HDD's are now arriving based around 4096-byte (a.k.a. 4k) sectors. The partitioning will still work with 512-bytes, but the drive's performance will be drastically impacted - in some testing it can be twice as slow, in others up to 25 times slower, depending on the sector alignment. So it's important to get this right!!!

=Alternative Parted usage=
Instead of the sequence of one liners up there, you can enter into parted itself like this. I give this as I don't know how your version of parted is going to behave. The interactive stuff from parted has been removed:
{{Code|
parted /dev/sdb
(parted) mklabel gpt
(parted) unit s
(parted) mkpart primary ext2 2048 -1
(parted) quit
}}

=Format the drive!=
Finally, let's get that drive formatted to a nice ext4 volume:
{{Code|
mkfs.ext4 -T largefile4 /dev/sdb1
}}

=Adding the drive to your HDA=
Normally to add a drive to Amahi, you would run the script '''hda-diskmount''', which searches for any unmounted drives and mounts them. Unfortunately, this script doesn't yet cater for GPT partitions. It runs an '''fdisk -l''' and searches out drives with a Linux system type, and with what it finds it mounts any that aren't mounted.

If we run '''fdisk -l''' by itself, we will see that our new drive doesn't return a system type of 'Linux', instead it returns 'GPT' as well as a warning:

{{Code|
Code= WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
}}

So hda-diskmount correctly ignores the drive. You can either [http://forums.amahi.org/viewtopic.php?f=15&t=2326 fix hda-diskmount], or you can manually mount the drives with the instructions below.

First we make our mount point

{{Code|
mkdir /var/hda/files/drives/sdb1
}}

Next we exercise good practice and backup our fstab file, I like to use `date +%Y%m%d` to give the name a date stamp e.g. /etc/fstab.20110731 represents a backup done on the 31st of July, 2011. This isn't necessary, you could just use something like 'fstab.old', but date-stamping your file backups is a good habit to get into
{{Code|
Code= cp /etc/fstab /etc/fstab.`date +%Y%m%d`
}}

Now we adjust the fstab file

{{Code|
Code= echo -e /dev/sdb1$'\t\t'/var/hda/files/drives/sdb1$'\t'ext4$'\t'defaults$'\t'1 1 >> /etc/fstab
}}

What this does is adds a line to the /etc/fstab file, telling it that when Amahi boots, it has to mount the drive. The $'\t' entries simply mean 'put in a tab space'

If you now run '''cat /etc/fstab''' you should see a nice entry at the bottom, similar to this

{{Code|
Code= cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Jul 28 23:56:48 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_hda-LogVol01 / ext4 defaults 1 1
UUID=cc1204dd-a4f8-42f8-8736-b5970251a865 /boot ext4 defaults 1 2
/dev/mapper/vg_hda-LogVol00 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sdb1 /var/hda/files/drives/sdb1 ext4 defaults 1 1
}}

Now you can either reboot to allow the fstab file to mount your new drive, or you can simply run '''mount -a'''

Now if you run mount by itself, you should see your drive listed e.g.

{{Code|
Code= mount
/dev/mapper/vg_hda-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdd1 on /media/520abb16-ac7c-4f65-9cc3-9e536c93dca2 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /var/hda/files/drives/sdb1 type ext4 (rw)
}}

=A note about Western Digital drives=
Western Digital make some nice hardware, but they are also incredibly stupid. Many of their hard drives will automatically park their heads every 8 seconds, which wears out the hard drives very quickly, in some cases the HDD's will reach their design limit (300k parks for consumer, 600k parks for enterprise) within 3-4 months!!! This isn't to say that the drives will necessarily die within 3-4 months, but it's still not good!

Fortunately we can fix this using a Western Digital tool named wdidle3. You can download it [http://support.wdc.com/product/download.asp?groupid=609&sid=113 here].

Create a bootable usb drive using [http://www.freedos.org/freedos/files/ FreeDOS] and [http://unetbootin.sourceforge.net/ unetbootin], then copy wdidle.exe onto the usb drive. Boot up your Amahi box to FreeDOS and enter the following commands:

{{Code|
c:\
wdidle3 /R
wdidle3 /S300
}}

This cd's you to the usb drive's root, then we run wdidle3 /R to display the current drive status, then we run wdidle3 /S300 to set the park time to 5 minutes. Alternatively you could run wdidle3 /D to completely disable the parking.

When you're done, simply restart the PC!

n.b. Unetbootin was a bit finnicky for me, I found that if I created the drive with a FreeDOS live CD that it wouldn't work, but if I then re-created using unetbootin's automatic distribution download feature, the USB stick worked a treat. YMMV.

Partitions Over 2.1 TB

2013-05-29T23:32:01Z

JoshTheBlack: /* Foreward */

=Foreward=
You cannot use a >=2.1TB partition as your boot device unless you have a UEFI bios. That is beyond the scope of this article.
When using a >=2.1TB partition, you should be running 64-bit Amahi.
Before you use a >=2.1TB drive on Windows, please read this support article: http://support.microsoft.com/kb/2581408

=Introduction=
As hard drives have increased in capacity over time, some clever workarounds have been engineered to keep breaking barriers, such as the move from CHS to LBA. Unfortunately, with older style MBR partitions, there is a limit of 2.1TB that simply cannot be worked around using an MBR partition. We have to instead use newer GPT style partitions.

I'm not going to delve into the history too much, you can google/wikipedia it yourself if you like.

So, if you've just purchased a snazzy new 3TB drive like a Western Digital Caviar Green, and you're scratching your head as to why you can't get the full capacity, here's the fix.

=Assumptions=
The below documentation assumes you have an existing boot drive with Amahi, namely /dev/sda. Your >2.1TB HDD will be /dev/sdb

The instructions also assume a Linux terminal, such as that on your Amahi box (either using its console, the Terminal application within the GUI, or SSH'd in)

=Warning=
BE ABSOLUTELY SURE THAT YOU ARE RUNNING THESE COMMANDS AGAINST THE CORRECT DRIVE. WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS, HARDWARE MALFUNCTION, ETC!

=OK, Let's do it=
First we label the drive with a GPT partition
{{Code|
parted /dev/sdb mklabel gpt
}}

Now we select sectors as a unit of measurement
{{Code|
parted /dev/sdb unit s
}}

Now we make the partition.
{{Code|
parted /dev/sdb mkpart primary ext2 2048 -1
}}
Parted may complain about the last sector and will automatically suggest a correct sector, just say Yes to the prompt.

We make it as a primary partition, ext2 filesystem, and we carefully select the sectors. The first number MUST be divisible by 8, so you can try 40, 48, 56, 64 etc... For me these numbers threw up errors, so I just went to 2048 and everything worked fine, and in the grand scheme of a 3TB drive, the extra sectors don't really matter :)

The reason that the starting sector is divisible by 8 is for aligning the sectors. This is because HDD's have traditionally been based around 512-byte sectors, yet newer, higher capacity HDD's are now arriving based around 4096-byte (a.k.a. 4k) sectors. The partitioning will still work with 512-bytes, but the drive's performance will be drastically impacted - in some testing it can be twice as slow, in others up to 25 times slower, depending on the sector alignment. So it's important to get this right!!!

=Alternative Parted usage=
Instead of the sequence of one liners up there, you can enter into parted itself like this. I give this as I don't know how your version of parted is going to behave. The interactive stuff from parted has been removed:
{{Code|
parted /dev/sdb
(parted) mklabel gpt
(parted) unit s
(parted) mkpart primary ext2 2048 -1
(parted) quit
}}

=Format the drive!=
Finally, let's get that drive formatted to a nice ext4 volume:
{{Code|
mkfs.ext4 -T largefile4 /dev/sdb1
}}

=Adding the drive to your HDA=
Normally to add a drive to Amahi, you would run the script '''hda-diskmount''', which searches for any unmounted drives and mounts them. Unfortunately, this script doesn't yet cater for GPT partitions. It runs an '''fdisk -l''' and searches out drives with a Linux system type, and with what it finds it mounts any that aren't mounted.

If we run '''fdisk -l''' by itself, we will see that our new drive doesn't return a system type of 'Linux', instead it returns 'GPT' as well as a warning:

{{Code|
Code= WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
}}

So hda-diskmount correctly ignores the drive. You can either [http://forums.amahi.org/viewtopic.php?f=15&t=2326 fix hda-diskmount], or you can manually mount the drives with the instructions below.

First we make our mount point

{{Code|
mkdir /var/hda/files/drives/sdb1
}}

Next we exercise good practice and backup our fstab file, I like to use `date +%Y%m%d` to give the name a date stamp e.g. /etc/fstab.20110731 represents a backup done on the 31st of July, 2011. This isn't necessary, you could just use something like 'fstab.old', but date-stamping your file backups is a good habit to get into
{{Code|
Code= cp /etc/fstab /etc/fstab.`date +%Y%m%d`
}}

Now we adjust the fstab file

{{Code|
Code= echo -e /dev/sdb1$'\t\t'/var/hda/files/drives/sdb1$'\t'ext4$'\t'defaults$'\t'1 1 >> /etc/fstab
}}

What this does is adds a line to the /etc/fstab file, telling it that when Amahi boots, it has to mount the drive. The $'\t' entries simply mean 'put in a tab space'

If you now run '''cat /etc/fstab''' you should see a nice entry at the bottom, similar to this

{{Code|
Code= cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Jul 28 23:56:48 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_hda-LogVol01 / ext4 defaults 1 1
UUID=cc1204dd-a4f8-42f8-8736-b5970251a865 /boot ext4 defaults 1 2
/dev/mapper/vg_hda-LogVol00 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sdb1 /var/hda/files/drives/sdb1 ext4 defaults 1 1
}}

Now you can either reboot to allow the fstab file to mount your new drive, or you can simply run '''mount -a'''

Now if you run mount by itself, you should see your drive listed e.g.

{{Code|
Code= mount
/dev/mapper/vg_hda-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdd1 on /media/520abb16-ac7c-4f65-9cc3-9e536c93dca2 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /var/hda/files/drives/sdb1 type ext4 (rw)
}}

=A note about Western Digital drives=
Western Digital make some nice hardware, but they are also incredibly stupid. Many of their hard drives will automatically park their heads every 8 seconds, which wears out the hard drives very quickly, in some cases the HDD's will reach their design limit (300k parks for consumer, 600k parks for enterprise) within 3-4 months!!! This isn't to say that the drives will necessarily die within 3-4 months, but it's still not good!

Fortunately we can fix this using a Western Digital tool named wdidle3. You can download it [http://support.wdc.com/product/download.asp?groupid=609&sid=113 here].

Create a bootable usb drive using [http://www.freedos.org/freedos/files/ FreeDOS] and [http://unetbootin.sourceforge.net/ unetbootin], then copy wdidle.exe onto the usb drive. Boot up your Amahi box to FreeDOS and enter the following commands:

{{Code|
c:\
wdidle3 /R
wdidle3 /S300
}}

This cd's you to the usb drive's root, then we run wdidle3 /R to display the current drive status, then we run wdidle3 /S300 to set the park time to 5 minutes. Alternatively you could run wdidle3 /D to completely disable the parking.

When you're done, simply restart the PC!

n.b. Unetbootin was a bit finnicky for me, I found that if I created the drive with a FreeDOS live CD that it wouldn't work, but if I then re-created using unetbootin's automatic distribution download feature, the USB stick worked a treat. YMMV.

Partitions Over 2.1 TB

2013-05-29T23:31:49Z

JoshTheBlack: /* Foreward */

=Foreward=
You cannot use a >=2.1TB partition as your boot device unless you have a UEFI bios. That is beyond the scope of this article.

When using a >=2.1TB partition, you should be running 64-bit Amahi.

Before you use a >=2.1TB drive on Windows, please read this support article: http://support.microsoft.com/kb/2581408

=Introduction=
As hard drives have increased in capacity over time, some clever workarounds have been engineered to keep breaking barriers, such as the move from CHS to LBA. Unfortunately, with older style MBR partitions, there is a limit of 2.1TB that simply cannot be worked around using an MBR partition. We have to instead use newer GPT style partitions.

I'm not going to delve into the history too much, you can google/wikipedia it yourself if you like.

So, if you've just purchased a snazzy new 3TB drive like a Western Digital Caviar Green, and you're scratching your head as to why you can't get the full capacity, here's the fix.

=Assumptions=
The below documentation assumes you have an existing boot drive with Amahi, namely /dev/sda. Your >2.1TB HDD will be /dev/sdb

The instructions also assume a Linux terminal, such as that on your Amahi box (either using its console, the Terminal application within the GUI, or SSH'd in)

=Warning=
BE ABSOLUTELY SURE THAT YOU ARE RUNNING THESE COMMANDS AGAINST THE CORRECT DRIVE. WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS, HARDWARE MALFUNCTION, ETC!

=OK, Let's do it=
First we label the drive with a GPT partition
{{Code|
parted /dev/sdb mklabel gpt
}}

Now we select sectors as a unit of measurement
{{Code|
parted /dev/sdb unit s
}}

Now we make the partition.
{{Code|
parted /dev/sdb mkpart primary ext2 2048 -1
}}
Parted may complain about the last sector and will automatically suggest a correct sector, just say Yes to the prompt.

We make it as a primary partition, ext2 filesystem, and we carefully select the sectors. The first number MUST be divisible by 8, so you can try 40, 48, 56, 64 etc... For me these numbers threw up errors, so I just went to 2048 and everything worked fine, and in the grand scheme of a 3TB drive, the extra sectors don't really matter :)

The reason that the starting sector is divisible by 8 is for aligning the sectors. This is because HDD's have traditionally been based around 512-byte sectors, yet newer, higher capacity HDD's are now arriving based around 4096-byte (a.k.a. 4k) sectors. The partitioning will still work with 512-bytes, but the drive's performance will be drastically impacted - in some testing it can be twice as slow, in others up to 25 times slower, depending on the sector alignment. So it's important to get this right!!!

=Alternative Parted usage=
Instead of the sequence of one liners up there, you can enter into parted itself like this. I give this as I don't know how your version of parted is going to behave. The interactive stuff from parted has been removed:
{{Code|
parted /dev/sdb
(parted) mklabel gpt
(parted) unit s
(parted) mkpart primary ext2 2048 -1
(parted) quit
}}

=Format the drive!=
Finally, let's get that drive formatted to a nice ext4 volume:
{{Code|
mkfs.ext4 -T largefile4 /dev/sdb1
}}

=Adding the drive to your HDA=
Normally to add a drive to Amahi, you would run the script '''hda-diskmount''', which searches for any unmounted drives and mounts them. Unfortunately, this script doesn't yet cater for GPT partitions. It runs an '''fdisk -l''' and searches out drives with a Linux system type, and with what it finds it mounts any that aren't mounted.

If we run '''fdisk -l''' by itself, we will see that our new drive doesn't return a system type of 'Linux', instead it returns 'GPT' as well as a warning:

{{Code|
Code= WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
}}

So hda-diskmount correctly ignores the drive. You can either [http://forums.amahi.org/viewtopic.php?f=15&t=2326 fix hda-diskmount], or you can manually mount the drives with the instructions below.

First we make our mount point

{{Code|
mkdir /var/hda/files/drives/sdb1
}}

Next we exercise good practice and backup our fstab file, I like to use `date +%Y%m%d` to give the name a date stamp e.g. /etc/fstab.20110731 represents a backup done on the 31st of July, 2011. This isn't necessary, you could just use something like 'fstab.old', but date-stamping your file backups is a good habit to get into
{{Code|
Code= cp /etc/fstab /etc/fstab.`date +%Y%m%d`
}}

Now we adjust the fstab file

{{Code|
Code= echo -e /dev/sdb1$'\t\t'/var/hda/files/drives/sdb1$'\t'ext4$'\t'defaults$'\t'1 1 >> /etc/fstab
}}

What this does is adds a line to the /etc/fstab file, telling it that when Amahi boots, it has to mount the drive. The $'\t' entries simply mean 'put in a tab space'

If you now run '''cat /etc/fstab''' you should see a nice entry at the bottom, similar to this

{{Code|
Code= cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Jul 28 23:56:48 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_hda-LogVol01 / ext4 defaults 1 1
UUID=cc1204dd-a4f8-42f8-8736-b5970251a865 /boot ext4 defaults 1 2
/dev/mapper/vg_hda-LogVol00 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sdb1 /var/hda/files/drives/sdb1 ext4 defaults 1 1
}}

Now you can either reboot to allow the fstab file to mount your new drive, or you can simply run '''mount -a'''

Now if you run mount by itself, you should see your drive listed e.g.

{{Code|
Code= mount
/dev/mapper/vg_hda-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdd1 on /media/520abb16-ac7c-4f65-9cc3-9e536c93dca2 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /var/hda/files/drives/sdb1 type ext4 (rw)
}}

=A note about Western Digital drives=
Western Digital make some nice hardware, but they are also incredibly stupid. Many of their hard drives will automatically park their heads every 8 seconds, which wears out the hard drives very quickly, in some cases the HDD's will reach their design limit (300k parks for consumer, 600k parks for enterprise) within 3-4 months!!! This isn't to say that the drives will necessarily die within 3-4 months, but it's still not good!

Fortunately we can fix this using a Western Digital tool named wdidle3. You can download it [http://support.wdc.com/product/download.asp?groupid=609&sid=113 here].

Create a bootable usb drive using [http://www.freedos.org/freedos/files/ FreeDOS] and [http://unetbootin.sourceforge.net/ unetbootin], then copy wdidle.exe onto the usb drive. Boot up your Amahi box to FreeDOS and enter the following commands:

{{Code|
c:\
wdidle3 /R
wdidle3 /S300
}}

This cd's you to the usb drive's root, then we run wdidle3 /R to display the current drive status, then we run wdidle3 /S300 to set the park time to 5 minutes. Alternatively you could run wdidle3 /D to completely disable the parking.

When you're done, simply restart the PC!

n.b. Unetbootin was a bit finnicky for me, I found that if I created the drive with a FreeDOS live CD that it wouldn't work, but if I then re-created using unetbootin's automatic distribution download feature, the USB stick worked a treat. YMMV.

Partitions Over 2.1 TB

2013-05-29T23:31:37Z

JoshTheBlack: Added foreward

=Foreward=
You cannot use a >=2.1TB partition as your boot device unless you have a UEFI bios. That is beyond the scope of this article.
When using a >=2.1TB partition, you should be running 64-bit Amahi.
Before you use a >=2.1TB drive on Windows, please read this support article: http://support.microsoft.com/kb/2581408

=Introduction=
As hard drives have increased in capacity over time, some clever workarounds have been engineered to keep breaking barriers, such as the move from CHS to LBA. Unfortunately, with older style MBR partitions, there is a limit of 2.1TB that simply cannot be worked around using an MBR partition. We have to instead use newer GPT style partitions.

I'm not going to delve into the history too much, you can google/wikipedia it yourself if you like.

So, if you've just purchased a snazzy new 3TB drive like a Western Digital Caviar Green, and you're scratching your head as to why you can't get the full capacity, here's the fix.

=Assumptions=
The below documentation assumes you have an existing boot drive with Amahi, namely /dev/sda. Your >2.1TB HDD will be /dev/sdb

The instructions also assume a Linux terminal, such as that on your Amahi box (either using its console, the Terminal application within the GUI, or SSH'd in)

=Warning=
BE ABSOLUTELY SURE THAT YOU ARE RUNNING THESE COMMANDS AGAINST THE CORRECT DRIVE. WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS, HARDWARE MALFUNCTION, ETC!

=OK, Let's do it=
First we label the drive with a GPT partition
{{Code|
parted /dev/sdb mklabel gpt
}}

Now we select sectors as a unit of measurement
{{Code|
parted /dev/sdb unit s
}}

Now we make the partition.
{{Code|
parted /dev/sdb mkpart primary ext2 2048 -1
}}
Parted may complain about the last sector and will automatically suggest a correct sector, just say Yes to the prompt.

We make it as a primary partition, ext2 filesystem, and we carefully select the sectors. The first number MUST be divisible by 8, so you can try 40, 48, 56, 64 etc... For me these numbers threw up errors, so I just went to 2048 and everything worked fine, and in the grand scheme of a 3TB drive, the extra sectors don't really matter :)

The reason that the starting sector is divisible by 8 is for aligning the sectors. This is because HDD's have traditionally been based around 512-byte sectors, yet newer, higher capacity HDD's are now arriving based around 4096-byte (a.k.a. 4k) sectors. The partitioning will still work with 512-bytes, but the drive's performance will be drastically impacted - in some testing it can be twice as slow, in others up to 25 times slower, depending on the sector alignment. So it's important to get this right!!!

=Alternative Parted usage=
Instead of the sequence of one liners up there, you can enter into parted itself like this. I give this as I don't know how your version of parted is going to behave. The interactive stuff from parted has been removed:
{{Code|
parted /dev/sdb
(parted) mklabel gpt
(parted) unit s
(parted) mkpart primary ext2 2048 -1
(parted) quit
}}

=Format the drive!=
Finally, let's get that drive formatted to a nice ext4 volume:
{{Code|
mkfs.ext4 -T largefile4 /dev/sdb1
}}

=Adding the drive to your HDA=
Normally to add a drive to Amahi, you would run the script '''hda-diskmount''', which searches for any unmounted drives and mounts them. Unfortunately, this script doesn't yet cater for GPT partitions. It runs an '''fdisk -l''' and searches out drives with a Linux system type, and with what it finds it mounts any that aren't mounted.

If we run '''fdisk -l''' by itself, we will see that our new drive doesn't return a system type of 'Linux', instead it returns 'GPT' as well as a warning:

{{Code|
Code= WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
}}

So hda-diskmount correctly ignores the drive. You can either [http://forums.amahi.org/viewtopic.php?f=15&t=2326 fix hda-diskmount], or you can manually mount the drives with the instructions below.

First we make our mount point

{{Code|
mkdir /var/hda/files/drives/sdb1
}}

Next we exercise good practice and backup our fstab file, I like to use `date +%Y%m%d` to give the name a date stamp e.g. /etc/fstab.20110731 represents a backup done on the 31st of July, 2011. This isn't necessary, you could just use something like 'fstab.old', but date-stamping your file backups is a good habit to get into
{{Code|
Code= cp /etc/fstab /etc/fstab.`date +%Y%m%d`
}}

Now we adjust the fstab file

{{Code|
Code= echo -e /dev/sdb1$'\t\t'/var/hda/files/drives/sdb1$'\t'ext4$'\t'defaults$'\t'1 1 >> /etc/fstab
}}

What this does is adds a line to the /etc/fstab file, telling it that when Amahi boots, it has to mount the drive. The $'\t' entries simply mean 'put in a tab space'

If you now run '''cat /etc/fstab''' you should see a nice entry at the bottom, similar to this

{{Code|
Code= cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Jul 28 23:56:48 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_hda-LogVol01 / ext4 defaults 1 1
UUID=cc1204dd-a4f8-42f8-8736-b5970251a865 /boot ext4 defaults 1 2
/dev/mapper/vg_hda-LogVol00 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sdb1 /var/hda/files/drives/sdb1 ext4 defaults 1 1
}}

Now you can either reboot to allow the fstab file to mount your new drive, or you can simply run '''mount -a'''

Now if you run mount by itself, you should see your drive listed e.g.

{{Code|
Code= mount
/dev/mapper/vg_hda-LogVol01 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sdd1 on /media/520abb16-ac7c-4f65-9cc3-9e536c93dca2 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /var/hda/files/drives/sdb1 type ext4 (rw)
}}

=A note about Western Digital drives=
Western Digital make some nice hardware, but they are also incredibly stupid. Many of their hard drives will automatically park their heads every 8 seconds, which wears out the hard drives very quickly, in some cases the HDD's will reach their design limit (300k parks for consumer, 600k parks for enterprise) within 3-4 months!!! This isn't to say that the drives will necessarily die within 3-4 months, but it's still not good!

Fortunately we can fix this using a Western Digital tool named wdidle3. You can download it [http://support.wdc.com/product/download.asp?groupid=609&sid=113 here].

Create a bootable usb drive using [http://www.freedos.org/freedos/files/ FreeDOS] and [http://unetbootin.sourceforge.net/ unetbootin], then copy wdidle.exe onto the usb drive. Boot up your Amahi box to FreeDOS and enter the following commands:

{{Code|
c:\
wdidle3 /R
wdidle3 /S300
}}

This cd's you to the usb drive's root, then we run wdidle3 /R to display the current drive status, then we run wdidle3 /S300 to set the park time to 5 minutes. Alternatively you could run wdidle3 /D to completely disable the parking.

When you're done, simply restart the PC!

n.b. Unetbootin was a bit finnicky for me, I found that if I created the drive with a FreeDOS live CD that it wouldn't work, but if I then re-created using unetbootin's automatic distribution download feature, the USB stick worked a treat. YMMV.