Posts by ikogan

    Even if some of the features aren't supported, that doesn't mean that a pool cannot be imported. It really depends on which features you're using on your pool and which are supported (or how well) on ZoL. Use `zpool get all ${your pool}` to see which features you're using and then you can check the `zpool-features` man page to see which are supported. ZoL's man page in source form is available here https://github.com/zfsonlinux/…man/man5/zpool-features.5. On my system, it lists:


    async_destroy, empty_bpobj, filesystem_limits, lz4_compress, spacemap_histogram, extensible_dataset, bookmarks, enabled_txg, hole_birth, embedded_data, large blocks


    As always, backups are a great idea.

    I've been running with lz4...always, for years. I think that unless your server is a potato, you should be fine performance wise. In terms of compression ratio...I doubt you'll see much if the only thing on your filesystem is compressed video.

    Quote

    Could you please provide some reference as to why the file system created by "zpool create" shouldn't be used for data storage? Waht makes it any different than other file systems created by ZFS?


    Well, there are some issues with data being on the root FS of a pool, I believe mainly to do with `zfs send`. From what I read, but not experienced, `zfs send` needs to be able to create all of the filesystems on the remote, and it can't do that with the root fs, so none of those files will send. Although, I cannot find any real documentation that talks about this situation.


    From: http://www.solarisinternals.co…/ZFS_Best_Practices_Guide


    Code
    Consider using the top-level dataset as a container for other file systems. The top-level dataset cannot be destroyed or renamed. You can export and import the pool with a new name to change the name of the top-level dataset, but this operation would also change the name of the pool. If you want to snapshot, clone, or promote file system data then create separate file systems in your pool. File systems provide points of administration that allow you to manage different sets of data within the same pool.


    I feel like it would be a bit counterintuitive to have the UI auto-create a child dataset and force you to deal with it. If you want to follow this best practice, then create some data sets after creating the pool.

    You can create a Dockerfile similar to the following:



    That's an example, it probably isn't complete. You can build the container with `docker build -t yourname/airdcnano` in the directory containing the Dockerfile. It may be worthwhile to put the last RUN command into a script instead, I would read the Dockerfile documentation.


    However. It looks like airdcnano is a GUI app, or are you trying to use it's text mode?

    Can you try to start your container manually rather than through the GUI? I'm not sure if they have any sort of entrypoint. I don't think they're meant to be run directly but rather have images created off of them? When you run the image, are you giving it any sort of entrypoint in the GUI? You should be able to specify one in the "Extra Arguments" section:


    Code
    --entrypoint=/bin/bash


    You should then be able to attach. Also, you may want to look into creating a Dockerfile instead of manually updating the image as it's a lot easier to update/maintain the image that way.