How can enable udev sync successfully in docker?

[NanXiao]

I have posted the issue on SO, unfortunately, there is no any answer. So I repost here, hope can get answer.

I have downloaded and install the static-linked docker 1.6.1 from this site, and run it on RHEL 7.1:

[root@localhost bin]# ./docker -d
WARN[0000] Udev sync is not supported. This will lead to unexpected behavior, data loss and errors
INFO[0000] +job init_networkdriver()
INFO[0000] +job serveapi(unix:///var/run/docker.sock)
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
INFO[0000] -job init_networkdriver() = OK (0)
INFO[0000] Loading containers: start.

INFO[0000] Loading containers: done.
INFO[0000] docker daemon: 1.6.1 97cd073; execdriver: native-0.2; graphdriver: devicemapper
INFO[0000] +job acceptconnections()
INFO[0000] -job acceptconnections() = OK (0)
INFO[0000] Daemon has completed initialization

I can see there is a warning: "Udev sync is not supported. This will lead to unexpected behavior, data loss and errors", and after checking the docker source code, I find the warning log is from deviceset.go:

func (devices *DeviceSet) initDevmapper(doInit bool) error {
    ......

    // https://github.com/docker/docker/issues/4036
    if supported := devicemapper.UdevSetSyncSupport(true); !supported {
        log.Warnf("Udev sync is not supported. This will lead to unexpected behavior, data loss and errors")
    }
    log.Debugf("devicemapper: udev sync support: %v", devicemapper.UdevSyncSupported())

    ......
}

The devicemapper.UdevSetSyncSupport is like this:

// UdevSyncSupported returns whether device-mapper is able to sync with udev
//
// This is essential otherwise race conditions can arise where both udev and
// device-mapper attempt to create and destroy devices.
func UdevSyncSupported() bool {
    return DmUdevGetSyncSupport() != 0
}

// UdevSetSyncSupport allows setting whether the udev sync should be enabled.
// The return bool indicates the state of whether the sync is enabled.
func UdevSetSyncSupport(enable bool) bool {
    if enable {
        DmUdevSetSyncSupport(1)
    } else {
        DmUdevSetSyncSupport(0)
    }
    return UdevSyncSupported()
}

I can see the reason is enabling udev sync failed. How can enable udev sync successfully?

[GordonTheTurtle]

Hi!
If you are reporting a new issue, PLEASE make sure that does not have any duplicates already open.

We would like to take this time to remind you of the information we need to debug the problem you are seeing. This is an automated response so if this ticket is not about a bug, do not fret.

If you fail to provide this information within 7 days, we will close this because we cannot debug your issue. We can reopen whenever the information is provided.

Thank you.

Please see:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

Description of problem:


`docker version`:


`docker info`:


`uname -a`:


Environment details (AWS, VirtualBox, physical, etc.):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Actual Results:


Expected Results:


Additional info:

#ENEEDMOREINFO

[phemmer]

From poking around, this looks to be enabled via a compile-time option on the lvm2 package. Did you custom build the lvm2 package or is it the official one from the redhat repos?

[coolljt0725]

To enable udev sync, you have to use dynamic-linked docker binary

[NanXiao]

@phemmer:
@coolljt0725 :

Thanks very much for your comments firstly!

After checking the disassembly code of dm_udev_set_sync_support:

(gdb) disassemble dm_udev_set_sync_support
Dump of assembler code for function dm_udev_set_sync_support:
=> 0x0000000000a3e4e0 <+0>:     repz retq
End of assembler dump.

It is a empty function and does nothing, not mention set sync support. Does this mean this static-built docker binary is no-use?

[coolljt0725]

This is why we should use a dynamic-linked docker binary to enable udev sync

[NanXiao]

@coolljt0725 ： It seems that the static-linked binary is no-use. Why does it exist?

[cpuguy83]

@NanXiao Because most people don't use devicemapper and don't need udev sync.

Closing because this is a non-issue.

[pdericson]

@cpuguy83 what storage backend would you recommend for RHEL / CentOS 6.X or 7?

[pdericson]

@NanXiao docker 1.6.0 is available from epel-testing

[detro]

@cpuguy83

@NanXiao Because most people don't use devicemapper and don't need udev sync.
Closing because this is a non-issue.

Well, this is disappointing way to answer to say the least.

1. devicemapper is one of the supported backends
2. there is no "default always works" supported backend
3. anyone that I know that don't use Docker for "playing around" but have actual businesses to run, struggle to put their finger on a "this is the stable one" backend to use: we just try shit and stop using it when it falls apart

In my specific case, I ended up here after using BTRFS for months and recently started having Kernel Panic trouble. So I have to look for alternatives for Docker backend storage. I'm thinking to turn to Direct DataMapper with LVM (as this RedHat article suggests it as a good option), and after googling the same error reported by @NanXiao above, I hit a brickwall.

I have grown accustomed to the general lack of "production responsibility" of the whole Docker development team (many interesting conversations with the Boot2Docker folks), that nowdays I don't even bother to report an issue anymore - I just rely on my trustworthy colleagues inside my own company.

Next time someone raises an issue about a SUPPORTED feature of Docker, as much as most people don't use it, try to be more helpful.

[cpuguy83]

@detro My response was terse because there is a whole thread here explaining the issue... though I do see that it is a shitty response.

The reality of the issue is that no one really understood the cause of the issue with devicemapper until after the 1.6.0 release.
The issue of course being that with a statically linked binary, udev sync is impossible, and as such can cause corruption issues.
This was difficult for RedHat (who maintains the devicemapper driver) to pinpoint because they use a dynamically linked binary (which they provide in their repos).

Just after the 1.7.0 release docker started providing rpms and debs with dynamically linked binaries from the main install script @ get.docker.com (and apt repos to match).
With these binaries udev sync is supported and devicemapper should work fine.

Also, I totally agree, the graphdriver situation is not fantastic even today. BTRFS is not really ready for prime-time, overlay is too new (and also has lots of known issues), aufs is basically unsupported (as a project), devicemapper is slow.
This is part of the reason I created #13777, which would allow 3rd parties to write drivers for their proprietary back-ends as well as experiment more rapidly with new tech.

In any case, if you'd like to discuss feel free to ping me on IRC any time.

[detro]

@cpuguy83 I appreciate your answer. If there is a thread with more info and with detailed answers, you should always link it. As much as there is a search facility in GitHub now, it's always possible to miss topics. Plus I'd be probably right to assume that most people land on issues from a google search; probably their working hours; on a rush to get things done.

Unless it's a Docker contributor, it's unlikely that such person has time or knowledge to know how deep and complex the issue with backends in docker is.

Anyhow, your answer gives me some next step to take: given BTRFS and OverlayFS are both not ready for prime time, and AUFS is unsupported, I'll have to 1) move from Docker 1.5 2) try again direct devicemapper over LVM. Performance wise shouldn't be as bad as devicemapper loopback.