View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 3 posts ] 
Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Thu Dec 31, 2015 3:54 am 
Offline
Joined: Fri Nov 19, 2004 11:58 pm
Posts: 99
I am looking for some insights in why archlinux/linhes does what it does around /data/storage:

New single drive installation:

/etc/fstab
Code:
UUID=68284006-fd41-4a52-98a8-b174ef837c59    /data/storage/disk0    xfs    defaults,noatime    0  1
/data/storage/disk0     /data/storage/KINGSTONSV100S264G_08AB50077563   none    rw,bind 0       0

mythtv-setup
storage directories
Code:
 /data/storage/KINGSTONSV100S264G_08AB50077563/<something>

The OS mounts the device by an UUID(A) to a relative name(B).
Something then takes the relative name and maps it into a specific name (C) that is not its UUID
MythtvSetup then uses the specific name(C) for the base storage directories path.

If you need to replace the drive, you need to change the two fstab lines and three fstab parameter (A&B&C) and n mythtv-setup storage directories (C)

It would seem more initiative to change a single fstab line and single fstab parameter(A) and none of the mythtv-setup storage directories when replacing a drive.

Am I missing something?

My system has a hard drive for LinHes, a raid for storage, and soon an addition raid for more storage. I usually hot swap out the OS drive when upgrading attempt to restore linhes from backup use sym links that map the OS media folder to the raids' media folder. The changing mount/storage directory made upgrading much more difficult.


Top
 Profile  
 
PostPosted: Mon Jan 04, 2016 2:01 pm 
Offline
Site Admin
Joined: Fri Jun 11, 2004 7:58 am
Posts: 507
This is purely a linhes behavior and it's all driven by the program add_storage.py.
The idea behind add_storage is that adding a disk should be simple.
On boot, a scan is performed and if new storage is detected the system asks if the disk should be added.
If the answer is yes then the drive is partitioned, formatted, mounted, directories created and then allocated for mythtv. The mount points are in the form of /data/storage/$modelnum_$serialnum. This was chosen to make it easier to find the correct physical drive when working on the hardware. If it is not desired to auto add the device say no to the storage question and the drive is then ignored, leaving it up to the user to allocate however they want.

You are correct in how the drives get mounted.
Within /etc/fstab the kernel level device is referenced by UUID (A).
The mount point (C) is always of the form /data/storage/$modelnum_$serialnum with a symlink to /data/storage/diskX.
The one exception to that rule is the storage dir on the OS drive (disk0)
/data/storage/disk0 /data/storage/KINGSTONSV100S264G_08AB50077563, instead of a symlink a bind mount is used.

The symlinks for /data/storage/diskX are there for convenience and are not used for anything.

Granted this setup does require a few more steps when the OS drive gets replaced.
To make it easier add_storage.py has a --reconstruct option which will read the config files in /etc/storage.d and then recreate all the symlinks,mount points and fstab entries.
Hopefully that gives some insights and answers the question.


Top
 Profile  
 
PostPosted: Mon Jun 06, 2016 10:57 pm 
Offline
Joined: Fri Nov 19, 2004 11:58 pm
Posts: 99
jams wrote:
To make it easier add_storage.py has a --reconstruct option which will read the config files in /etc/storage.d and then recreate all the symlinks,mount points and fstab entries.


Tried the scripts again in R8.4, same issues around md UUID. However based on you comment I think I was able to get something semi automated this time:
Step 0: Get real UUIDs

Code:
 mdadm --detail --scan
One out of two of my mdadm raids reported a UUID that was not mountable with this command
Code:
 blkid
Both mdadm raids reported proper mountable UUIDs from this command
Step 1: Manual add each md raid to /etc/fstab using the md UUID
Code:
UUID=10484948-b1a9-4454-9719-8b9d8beb1dfb    /data/storage/raid   xfs    defaults,noatime    0    1

Step 2: Mount the drive
Code:
mount -a

Step 3: Copy the /etc/storage.d/HardDriveMang_id.conf to the name used as the md raid mount point in the /etc/fstab
Code:
cp /etc/storage.d/HardDriveManf_id.conf  /etc/storage.d/raid.conf

Step 4: Edit the new /etc/storage.d/raid.conf file, update the uuid, mountpoint, and disk_num
Code:
[storage]
uuid = 10484948-b1a9-4454-9719-8b9d8beb1dfb
mountpoint = /data/storage/raid
fstype = xfs
shareable = True
mmount = True
storage_groups = True
disk_num = 1

Step 5: Create symbolic links for diskN to point to the md mount point
Code:
ln -s /data/storage/raid /data/storage/disk1

Step 6: Run the add_storage.py script
Code:
 add_storage.py --reconstruct_sg


I have two raids and its created all the myth storage directories on raids that did not exist, and also preserved the ones that I manually created in the previous release to get around the previous Very cool.

I could not get the md drives to both mount and also bind to diskN in the /etc/fstab file like a non md drives do. I am not sure if step 5 can be skipped or not, but the mythtv storage groups does not require it. I added them links just in can something like the backup script references them over the mount points.


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 


All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 25 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu