-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZFS Support #13
Comments
|
@au-phiware I tried running the exact command that you provided and it worked ok for me. In my case I was using Docker for Windows, but I've done essentially the same thing recently on RHEL and Docker for Mac. I'm wondering - is that the exact command you used or did you possibly try mounting a volume using |
Hi @twright-msft, you are right I did run it with |
I have no doubt that there must be something particular about my kernel or filesystem. I use Gentoo and build my own kernel from git (the stable branch) but I'm not doing anything special there. I use zfs and so the docker storage driver is zfs too, could it be that there's an issue with accessing metadata or something else to do with the filesystem? |
Just to be sure I tried on my home machine (also Gentoo and ZFS) and used
|
We havent done any testing on Gentoo/zfs yet. It's definitely possible there is an issue there with the kernel/file system. |
Is there any further information that I can provide? Or turn on verbose
logging?
…On Fri, 13 Jan 2017, 12:30 AM Travis Wright ***@***.***> wrote:
We havent done any testing on Gentoo/zfs yet. It's definitely possible
there is an issue there with the kernel/file system.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAx2LutMzCdMoMYWB_5SqhkOvDcjEVLOks5rRirqgaJpZM4LgDrC>
.
|
I am having this exact same issue on Docker for windows. |
One thing to check, especially if you are using Docker for Windows or Docker for Mac is that you adjust the amount of RAM that Docker Engine has available to it. |
The mssql image shows a clear and specific error message when docker engine has less than 4gb ram available. This is not the error I was getting. After a full docker reset the issue seems to have gone away now though. |
having same issue and error message using mac and docker v1.13 with 4gb memory when mounting volume with -v option to bind /var/opt/mssql, we can see logs but .mdf id failing with error 87. workaround is to start without this -v option, it works, but .mdf file are inside container |
@laurentleseigneur This is a known issue with macOS and -v. We have a separate issue tracking that. #12 |
thanks @twright-msft for pointing this known issue, i will give a try to a docker compose using a container volume to store .mdf files |
I had the same error and I solved it by erasing the images and containers and re-creating them. Docker version 1.13.1, build 092cba3 |
@twright-msft Thanks for this thread; came here because I'm experiencing the same issue. I wanted to see if my case is a part of the known issue because I'm using mounted data volume containers. In my
But when I pull up the logs from
Is this part of the the known issue? |
@PatrickDePuydt Are you on MacOS or Linux? If Linux, what distribution/version are you running on? |
@twright-msft I'm running OS X Sierra but the base Docker image is a Centos7 |
@PatrickDePuydt OK, then yes, you are running into the issue I described above with using Docker for Mac and -v (volumes: in the way you are using it in docker-compose.yml is effectively docker run -v). Please use a 'data volume container' instead. |
@twright-msft Ok, thanks! Could you clear up one last thing? You mentioned using an attached Docker container volume for database file storage as a workaround, but isn't that what I'm doing in the volume declaration of the service: |
As I understand it what you are doing there is mounting a directory on the host to a directory in the container. That's what doesnt work on macOS. What you want to do is mount a volume container to a directory in the mssql container. |
This is an evaluation version. There are [156] days left in the evaluation period. I have the same problem but not in docker. it running and working in docker after pushing the docker image to heroku app it is giving the above message message. anybody has any idea about this issue. Thanks |
(I feels as if this thread has been hijacked by Mac users) I decided to take ZFS out of the mix:
This time I didn't receive the error, the container stayed up and I have an operational mssql server on linux! I guess the next question is: where does the fault lie? This project (seems unlikely)? Docker (more specifically the zfs storage driver)? Or ZFS? I think I'll close this issue and go ask Docker. For the record here's my working configuration:
|
Have you run any traces while it was running and then capturing the crash?
…
On May 14, 2017 at 7:23 PM, <Corin Lawson ***@***.***)> wrote:
(I feels as if this thread has been hijacked by Mac users)
I decided to take ZFS out of the mix:
First I confirmed I was still receiving the error with the latest image.
I create a zvol and formatted it with ext4 and mounted it as my /var/lib/docker directory.
Started the docker daemon and ensured it wasn't using zfs as the storage device.
Tried again.
This time I didn't receive the error, the container stayed up and I have an operational mssql server on linux!
I guess the next question is: where does the fault lie? This project (seems unlikely)? Docker (more specifically the zfs storage driver)? Or ZFS?
I think I'll close this issue and go ask Docker.
For the record here's my working configuration:
$ docker info Containers: 1 Running: 1 Paused: 0 Stopped: 0 Images: 2 Server Version: 1.12.1 Storage Driver: devicemapper Pool Name: docker-230:1-131073-pool Pool Blocksize: 65.54 kB Base Device Size: 10.74 GB Backing Filesystem: ext4 Data file: /dev/loop0 Metadata file: /dev/loop1 Data Space Used: 2.485 GB Data Space Total: 107.4 GB Data Space Available: 7.923 GB Metadata Space Used: 2.257 MB Metadata Space Total: 2.147 GB Metadata Space Available: 2.145 GB Thin Pool Minimum Free Space: 10.74 GB Udev Sync Supported: true Deferred Removal Enabled: false Deferred Deletion Enabled: false Deferred Deleted Device Count: 0 Data loop file: /var/lib/docker/devicemapper/devicemapper/data WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device. Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata Library Version: 1.02.93 (2015-01-30) Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host null overlay Swarm: inactive Runtimes: runc Default Runtime: runc Security Options: seccomp Kernel Version: 4.6.5-stable Operating System: Gentoo/Linux OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 15.59 GiB Name: tecknack-corin ID: JXJV:BP5E:T547:PZTF:4JSO:6SV5:B7EO:XA3U:EPV7:7Z5H:BS2Y:SAV7 Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): false Registry: https://index.docker.io/v1/ Insecure Registries: 127.0.0.0/8
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (#13 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAk8rXrpPZxLV7L8WbCyd5L3NKHVINDvks5r57cqgaJpZM4LgDrC).
|
Here is a full syscall trace from machine with zfsonlinux: Steps to reproduce
https://dl.thalheim.io/Z03MnoPGwbCXhJOXpBvgwg/sqlservr.log?dl=1 I tried to reason about the repeated sequence of syscalls (some strange enterprise retry handler), but found not failing syscall. Without access to the source code and the uninformative error message, I have no clue what's going on here. |
FWIW we have done zero testing on zfs. @au-phiware Please let us know the issue ID if you do raise this with Docker in a way that is publicly trackable. Thanks! |
The issue can be viewed at moby/moby#33191 |
@au-phiware I do not think docker is the best issue tracker for this, as we miss domain knowledge about mssql internals. |
@Mic92 yes, well I'm really not sure where to go... I'll try recreate the issue with docker removed from the mix. Is there a better issue tracker someplace or should I reopen this one? |
Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume.
…16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume.
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
An error appeared when attempting to run the container like ``` Setup FAILED copying system data file 'C:\templatedata\master.mdf' to '/var/opt/mssql/data/master.mdf' ``` By running as root the problem is fixed. See microsoft/mssql-docker#13 (comment)
IMHO this can be closed. ZFS now supports O_DIRECT out of the box, so no hack is necessary anymore. |
The issue has been abused (by me as well) for other file systems, too. |
this helped me solve my mistake, thank you |
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
…#16159) Seems that MSSQL is not able to use data volume when it is mounted from tmpfs filesystem. See microsoft/mssql-docker#13 In such case, instead of mounting docker-created volume we mount a volume mounted from home directory of the user which is unlikely to be a tmpfs volume. GitOrigin-RevId: 352fefaef1712bf5e60e3e79a86214279be69e16
Upon executing
docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=<YourStrong!Passw0rd>' -p 1433:1433 microsoft/mssql-server-linux
, I encounter the following message:The setup log contains:
The
/var/opt/mssql/data
directory contains:Please advise.
The text was updated successfully, but these errors were encountered: