[ovirt-devel] GFS2 mount via symlink problem

Enrico Tagliavini enrico.tagliavini at gmail.com
Thu May 15 12:30:37 UTC 2014


Hi Federico,

I agree with you, the 2 patched are now squashed. I left the unit test
aside since it requires some additional review. I'm without free time
to spend on this since I'm in the middle of a life change (new work +
new country), so I wrote it very quickly.

Kind regards
Enrico

On Tue, May 13, 2014 at 9:22 AM, Federico Simoncelli
<fsimonce at redhat.com> wrote:
> ----- Original Message -----
>> From: "Enrico Tagliavini" <enrico.tagliavini at gmail.com>
>> To: devel at ovirt.org
>> Sent: Thursday, May 8, 2014 1:15:15 PM
>> Subject: [ovirt-devel] GFS2 mount via symlink problem
>>
>> The storage is mounted twice, first by the gfs2 init script and then
>> by ovirt. As you can see even if both ovirt and gfs2 init script used
>> the /dev/mapper/name symlink, in proc mounts there is the real device
>> specified, the one the symlink is pointing to.
>>
>> I have no clue why only GFS2 does that (at least ext* FS are not,
>> didn't checked anything else TBO, I have only ext* FS on other LVM
>> volumes on the same system).
>>
>> In this case oVirt fails to check if the FS is mounted, since there is
>> no entry in /proc/mounts matching the device name specified (the
>> /dev/mapper/name one). I my example above I already applied a fix for
>> that, so it is actually working.
>>
>> I've submitted a fix to ovirt gerrit, see [2], [3] and [4] (the latter
>> is a unit test for checking gfs2). Note that [2] alone is not correct,
>> it needs [3] as well to not break some other setup.
>
> My suggestion is to squash the two patches if the first one is breaking
> the branch (they're not very large and it makes sense to keep the entire
> change together).
>
>> That said I still think this should be handled by ovirt. It doesn't
>> really matter if in /proc/mounts you have the symlink or the real
>> device, it is the same mount
>
> +1 to support this, after all we have to handle the fact that in some
> cases the symlinks may be resolved.
>
> --
> Federico



More information about the Devel mailing list