limetech Posted September 1, 2014 Author Share Posted September 1, 2014 After I run the server again it worked It is not clear why. I'm glad you got it going. There will be improvements to this moving forward. Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 Looking good! Quote Link to comment
NAS Posted September 1, 2014 Share Posted September 1, 2014 All seems to be working great, just re-downloading images now. Thanks! I wasn't 100% sure of the update order but i did the following. Deleted docker plg from plugins. Updated unraid to beta8 & reboot Ran btrfs subvolume delete Started docker and added new img path Ran CP for existing template move Deleted -boot/config/plugins/dockerMan.plg - /Docker-startup.plg - /dockerMan-2014.08.28.tar.gz I ahve to agree with this post. if you read the upgrade OP it isnt actually clear the correct order to do stuff. I suggest the above is validated and the OP updated ASAP so avoid any problems. Nice work. Quote Link to comment
cirkator Posted September 1, 2014 Share Posted September 1, 2014 Sorry for the question, but I have been out of the loop and don't quite understand it yet. On beta 4 I used a Linux vm on my cache disk and did all my downloading there. I wrote new downloads to the cache disk and mover then did it's job. Now with the new .img for docker, could I buy a, say, 64GB SSD and use that for the img storage and use my current cache disk as the download location?! So I would have the SSD just for docker and the 500GB cache as cache and download location. Would you recommend that procedure, or do you have any suggestions?! Am I understanding that right? I am not interested in cache pooling. Quote Link to comment
theone Posted September 1, 2014 Share Posted September 1, 2014 So as I understand it - We do not need a BTRFS formatted device anomore - It is handled by the image file created. correct? That is correct! But if you want redundancy in the 'cache' it has to be btrfs. For redundant cache do I need same size drives? if I use different size drives will I be limited to the smaller size drive? is it like raid 1? Quote Link to comment
StevenD Posted September 1, 2014 Share Posted September 1, 2014 What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1? In the posted notes, under 6.0-beta7-x86 64 it states the following. emhttp: removed automatic file system expand when small drive is replaced by bigger drive. This will be put back in next release. I guess there are more important things to work on. This cannot be that difficult. Why cant the commands be posted so we can extend the partitions ourselves? Quote Link to comment
SSD Posted September 1, 2014 Share Posted September 1, 2014 Great job Tom! One question for you... how are the instructions different for those of us who had a dedicated disk outside of the array for Docker (i.e. not cache drive). Right, if you enter the block device partition (eg, /dev/sdg1) in the field for "Docker image file" it will mount that btrfs partition onto /var/lib/docker. Kept that capability just for you, btw. Not recommended. This seems a rather fragile solution. The device designation could change boot to boot. Would there be a danger if the device changed and suddenly the device (e.g., /dev/sdg1) is assigned to an array disk or the parity disk or whatever? I currently have this in my go file ... #------------------- # mount btrfs (SSD) #------------------- mkdir -p /mnt/btrfs mount /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSCF31xxxxx-part1 /mnt/btrfs Could this be altered to do the equivalent of the configuration above in a more boot friendly way? Quote Link to comment
Owel Posted September 1, 2014 Share Posted September 1, 2014 How do I configure docker, to run on cache drive only? Quote Link to comment
sparkysplace Posted September 1, 2014 Share Posted September 1, 2014 I'm a tad confused. Right now I have /mnt/cache/docker and in there I have a directory called "appdata". In my docker apps, I use appdata as the "host path" for container volume. The instructions call to delete /mnt/cache/docker, but I'd like to keep my databases and configuration. Can I continue to use /mnt/cache/docker/appdata as the host path for container volumes or should I be migrating to something else? Quote Link to comment
BRiT Posted September 1, 2014 Share Posted September 1, 2014 What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1? In the posted notes, under 6.0-beta7-x86 64 it states the following. emhttp: removed automatic file system expand when small drive is replaced by bigger drive. This will be put back in next release. It seems like this question wasn't spotted with all the focus and excitement on docker. LimeTech, jonp, can you please indicate if this release beta8 has the ability to resize drives on rebuild if using ReiserFS? Quote Link to comment
BRiT Posted September 1, 2014 Share Posted September 1, 2014 What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1? In the posted notes, under 6.0-beta7-x86 64 it states the following. emhttp: removed automatic file system expand when small drive is replaced by bigger drive. This will be put back in next release. I guess there are more important things to work on. This cannot be that difficult. Why cant the commands be posted so we can extend the partitions ourselves? CAVEAT EMPTOR: I am not certain about this, but I think this you'd have to do so on the /dev/md# device while the /dev/disk# are unmounted. If your filesystem is ReiserFS, you can grow the filesystem using: /sbin/resize_reiserfs . The default behavior is to grow to use the available space and be verbose to show extra progress status messages. This must be done on an unmounted filesystem. If your filesystem is ext2, ext3, or ext4, you can grow the filesystem using: /sbin/resize2fs -p . The default behavior is to grow to use the available space. The -p option [lowercase p] means to be verbose to show extra progress status messages. This must be done on an unmounted filesystem. If your filesystem is btrfs, you can grow the filesystem using: btrfs . btrfs filesystem resize [<devid>:][+/-]<newsize>[gkm]|max <filesystem> Resize a filesystem identified by <path>. The <size> parameter specifies the new size of the filesystem. If the prefix + or - is present the size is increased or decreased by the quantity <size>. If no units are specified, the unit of the <size> parameter defaults to bytes. Optionally, the size parameter may be suffixed by one of the following the units designators: 'K', 'M', or 'G', kilobytes, megabytes, or gigabytes, respectively. If 'max' is passed, the filesystem will occupy all available space on the volume(s). Quote Link to comment
StevenD Posted September 1, 2014 Share Posted September 1, 2014 What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1? In the posted notes, under 6.0-beta7-x86 64 it states the following. emhttp: removed automatic file system expand when small drive is replaced by bigger drive. This will be put back in next release. I guess there are more important things to work on. This cannot be that difficult. Why cant the commands be posted so we can extend the partitions ourselves? CAVEAT EMPTOR: I am not certain about this, but I think this you'd have to do so on the /dev/md# device while the /dev/disk# are unmounted. If your filesystem is ReiserFS, you can grow the filesystem using: /sbin/resize_reiserfs . The default behavior is to grow to use the available space and be verbose to show extra progress status messages. This must be done on an unmounted filesystem. If your filesystem is ext2, ext3, or ext4, you can grow the filesystem using: /sbin/resize2fs -p . The default behavior is to grow to use the available space. The -p option [lowercase p] means to be verbose to show extra progress status messages. This must be done on an unmounted filesystem. If your filesystem is btrfs, you can grow the filesystem using: btrfs . btrfs filesystem resize [<devid>:][+/-]<newsize>[gkm]|max <filesystem> Resize a filesystem identified by <path>. The <size> parameter specifies the new size of the filesystem. If the prefix + or - is present the size is increased or decreased by the quantity <size>. If no units are specified, the unit of the <size> parameter defaults to bytes. Optionally, the size parameter may be suffixed by one of the following the units designators: 'K', 'M', or 'G', kilobytes, megabytes, or gigabytes, respectively. If 'max' is passed, the filesystem will occupy all available space on the volume(s). Thanks. I appreciate this. However, Tom has posted several times that he will post the "supported" procedure for doing this. I'm going to wait for him to do so. Quote Link to comment
itimpi Posted September 1, 2014 Share Posted September 1, 2014 Any good reason for the SSD? I would have thought that it is easy enough to store the docker.img file on the cache disk as well. That is what I have done Quote Link to comment
bungee91 Posted September 1, 2014 Share Posted September 1, 2014 I'm at a loss here, everything was well in Beta 7, now this docker move fiasco and everything is broken! I likely did everything wrong, didn't properly backup, and likely lost my MariaDB database. So help is appreciated. This is what I have at this point, a basically fresh Beta 8 install. Under extensions I have docker, it does nothing. If I click start, it does not. In that page it says docker image /mnt/disk1/docker.img I don't have one there, no clue if I'm supposed to put one there?.. So I hit start, it does nothing. Do I need to put an image there, was it supposed to do this automatically and I fucked it up? Damn did this all work well before prior to this upgrade! It states that "When you visit the Extensions/Docker page you will notice a box to enter a Docker image file. When you click 'Start' the file name you specify will be created and a btrfs file system will be created inside that file. Next the file is loop mounted onto /var/lib/docker. You are also able to resize the file (expand only, shrink not supported yet), and scrub (check) the file system. The default size of "10" (meaning 10GB) seems reasonable to start with." I never get an option to "enter a docker image file" it is listed as disk 1 and greyed out. When I hit start it does nothing, nada.. Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 I never get an option to "enter a docker image file" it is listed as disk 1 and greyed out. When I hit start it does nothing, nada.. That text you see greyed out is called a "placeholder" - it's just an example of what you can type. Click in the box and you will see it turn blank and you can enter filename path such as /mnt/disk1/docker.img [will be created in root of /mnt/disk1] or /mnt/disk1/docker/docker.img [directory, aka share, docker must already exist] You don't have to use /mnt/disk1. Could use /mnt/disk2 or /mnt/cache. You don't have to name it docker.img. Could be docker1.img or my-docker.img or test-docker.img You don't have to give it an img extension. Could give it any extension or no extension. RIGHT this could be implemented a bit clearer - I'm not a fan of the 'placeholder' attribute because of this exact possible confusion. BUT this is BETA software. Rough edges are to be expected and some understanding and willingness to look at some code (eg. /etec/rc.d/rc.docker) goes a long way to understand what the s/w is trying to achieve. Edit: the reason an actual default is not in that 'Docker image' field is because upon first boot it would use it! And maybe you don't want it that way. Also if you leave the field blank it effectively disables docker - it won't load at all - for those who don't want Docker. Quote Link to comment
sparkysplace Posted September 1, 2014 Share Posted September 1, 2014 I never get an option to "enter a docker image file" it is listed as disk 1 and greyed out. When I hit start it does nothing, nada.. It's grayed out as an example. Click on the box and type your path to wherever you want your docker img to be located (I have mine on my cache drive (that I don't use as cache), as I didn't see the point of having it on the array) Hit start, follow the rest of the directions. If you've already deleted your docker directory on the cache drive, then yeah, you probably lost your database and whatever else you were previously using unless you have a copy on the array. I kept my previous cache/docker host container directories and asked the question about it a few posts up (not answered yet) because it isn't very clear. I think they assume your docker's data is stored on the array, which obviously isn't the case for everyone. I thought I'd add that after moving over my existing templates and re-downloading, everything works as well as before. If the benefit of having the loopback image is for ease-of-backup, I'm not convinced of the benefits vs just allowing us to add an additional "non-cache non-array data drive" in unraid. I still have to deal with container volumes and host paths that are outside of the image - unless I should be using host paths IN the image. Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 I likely did everything wrong, didn't properly backup, and likely lost my MariaDB database. Where exactly was it located before? Meaning what was the file path? Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 So as I understand it - We do not need a BTRFS formatted device anomore - It is handled by the image file created. correct? That is correct! But if you want redundancy in the 'cache' it has to be btrfs. For redundant cache do I need same size drives? if I use different size drives will I be limited to the smaller size drive? is it like raid 1? A google search and a little reading goes a long way: https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_space_do_I_get_with_unequal_devices_in_RAID-1_mode.3F Quote Link to comment
bungee91 Posted September 1, 2014 Share Posted September 1, 2014 Thank you to the both of you, and I apologize for my frustration. I understand the "beta" part, and also understand the need for the change even though I didn't experience the out of space issues yet. The greyed out area was odd, it took me a couple of clicks and it allowed me to type. I assumed the initial place for /mnt/disk1 when I hit start would do something, however it just changed for a second and went back to stopped. This must be because it is merely a suggested place, and not actually typed as the location. So when I hit start, it didn't have a location to go to so it failed. Now that I was able to type /mnt/cache/docker.img it created it just fine, did it's thing, and now it is running!!! I did backup the programs I had as far as the directory, and I also have their templates. I will now continue to attempt to get them back setup. Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 Great job Tom! One question for you... how are the instructions different for those of us who had a dedicated disk outside of the array for Docker (i.e. not cache drive). Right, if you enter the block device partition (eg, /dev/sdg1) in the field for "Docker image file" it will mount that btrfs partition onto /var/lib/docker. Kept that capability just for you, btw. Not recommended. This seems a rather fragile solution. The device designation could change boot to boot. Would there be a danger if the device changed and suddenly the device (e.g., /dev/sdg1) is assigned to an array disk or the parity disk or whatever? I currently have this in my go file ... #------------------- # mount btrfs (SSD) #------------------- mkdir -p /mnt/btrfs mount /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSCF31xxxxx-part1 /mnt/btrfs Could this be altered to do the equivalent of the configuration above in a more boot friendly way? I think you should be able to use '/dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSCF31xxxxx-part1' as the 'Docker image:' - did you try it? Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 What is the state of automatic file system expansion when a drive is replaced with a larger capacity drive? Is this in beta8 or not until beta9/beta10. Or by release do you mean 6.1? In the posted notes, under 6.0-beta7-x86 64 it states the following. emhttp: removed automatic file system expand when small drive is replaced by bigger drive. This will be put back in next release. I guess there are more important things to work on. This cannot be that difficult. Why cant the commands be posted so we can extend the partitions ourselves? If it's reiserfs and it's that critical to you, you can boot -beta6, let it do it's thing, then put -beta8 back on. Quote Link to comment
limetech Posted September 1, 2014 Author Share Posted September 1, 2014 I'm a tad confused. Right now I have /mnt/cache/docker and in there I have a directory called "appdata". In my docker apps, I use appdata as the "host path" for container volume. In your case you shouldn't delete /mnt/cache/docker if you have your app data in there too. The instructions call to delete /mnt/cache/docker, but I'd like to keep my databases and configuration. Can I continue to use /mnt/cache/docker/appdata as the host path for container volumes or should I be migrating to something else? Personally I would have a share named 'appdata', then you can put it anywhere that makes sense. Quote Link to comment
bungee91 Posted September 1, 2014 Share Posted September 1, 2014 Alright, I'm calm now and good to go! The only docker I really cared about was MariaDB and my XBMC library. Once I transferred it's template I installed it, stopped the newly made docker, replaced the new folder with my old (backed up) MariaDB program folder, and it started and worked perfectly!! I apologize for my frustration, it was frustrating and I always think "I've got this, no problem" and, well, ... nope. I should backup better just in case in the future. All is well.. Quote Link to comment
fiscalcon Posted September 1, 2014 Share Posted September 1, 2014 All seems to be working great, just re-downloading images now. Thanks! I wasn't 100% sure of the update order but i did the following. Deleted docker plg from plugins. Updated unraid to beta8 & reboot Ran btrfs subvolume delete Started docker and added new img path Ran CP for existing template move Deleted -boot/config/plugins/dockerMan.plg - /Docker-startup.plg - /dockerMan-2014.08.28.tar.gz Ran this same process, so far so good. Yet to test anything on it though (plex, etc.). But I was able to re-download images just fine using my previous templates. Did a reboot with all docker images set to auto start, things came up like they did in beta6. APC UPS appears to still be working, status is good in the UI (untested though by unplugging power to UPS). Appreciate the walkthrough! I'll update once I've started using it for watching shows. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.