Файловая система, смонтированная поверх «/», недоступна - так почему ее можно размонтировать с помощью «umount /»?

Мне также удалось найти уникальное устройство в / dev / serial / by-id . Я еще не пробовал перезагрузку, но файлы в этом каталоге были просто ссылками на соответствующий файл устройства ( ttyACM [0-9] ). «

Я использую Arch Linux на Raspberry Pi , но я наткнулся на них, просто выполнив find для имен файлов, содержащих "Arduino". Мои программы на Python отлично работают, используя эти файлы в качестве устройств для чтения / записи данных в / из моих Arduinos (пока что два на одном Pi).

1
19.07.2018, 15:10
1 ответ

Глядя внутрь Linux v4.17, я думаю, мы можем сказать, что umountна /эквивалентно umountна /... И /..получает доступ к «верху [] кучи точек монтирования».

# stat -f / --format %T
ext2/ext3
# stat -f /.. --format %T
tmpfs

Такое непонятное поведение .., кажется, разрешено POSIX. В нем только говорится: «В особом случае в корневом каталоге точка -точка может относиться к самому корневому каталогу». (POSIX.1 -2017, раздел 4.13 «Разрешение пути» ).

Если вы хотите обобщить это и определить поведение, реализованное umountна других точках монтирования, сравнение с ..не работает так хорошо. Термин «верхняя часть кучи точек монтирования» по-прежнему применим, хотя и не звучит как очень формальное определение :).

Исходный код ядра

https://elixir.bootlin.com/linux/v4.17/source/fs/namei.c

Посмотрите, где path_mountpoint()вызывает follow_mount().

/**
 * path_mountpoint - look up a path to be umounted
 * @nd:     lookup context
 * @flags:  lookup flags
 * @path:   pointer to container for result
 *
 * Look up the given name, but don't attempt to revalidate the last component.
 * Returns 0 and "path" will be valid on success; Returns error otherwise.
 */
static int
path_mountpoint(struct nameidata *nd, unsigned flags, struct path *path)
{
    const char *s = path_init(nd, flags);
    int err;
    if (IS_ERR(s))
        return PTR_ERR(s);
    while (!(err = link_path_walk(s, nd)) &&
        (err = mountpoint_last(nd)) > 0) {
        s = trailing_symlink(nd);
        if (IS_ERR(s)) {
            err = PTR_ERR(s);
            break;
        }
    }
    if (!err) {
        *path = nd->path;
        nd->path.mnt = NULL;
        nd->path.dentry = NULL;
        follow_mount(path);
    }
    terminate_walk(nd);
    return err;
}

Комментарий для follow_mount()звучал так, как будто он имел отношение к вопросу. И он упоминает follow_dotdot()как основного пользователя, предложившего это направление расследования.

/*
 * Skip to top of mountpoint pile in refwalk mode for follow_dotdot()
 */
static void follow_mount(struct path *path)
{
    while (d_mountpoint(path->dentry)) {
        struct vfsmount *mounted = lookup_mnt(path);
        if (!mounted)
            break;
        dput(path->dentry);
        mntput(path->mnt);
        path->mnt = mounted;
        path->dentry = dget(mounted->mnt_root);
    }
}

static int follow_dotdot(struct nameidata *nd)

Я думал о том, как..("dotdot" )может перемещаться от точки монтирования к своему родителю, например. /tmp/... Но я раньше не думал, что это может «перейти к [] вершине [] кучи точек монтирования». Это происходит даже в том случае, если верхнее монтирование не содержит исходный каталог /tmp!

2
27.01.2020, 23:31

Теги

Похожие вопросы