<div dir="ltr">В линуксе mount --bind /dev /mnt/dev ЕМНИП<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 30, 2018 at 1:46 PM, Slawa Olhovchenkov <span dir="ltr"><<a href="mailto:slw@zxy.spb.ru" target="_blank">slw@zxy.spb.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 29, 2018 at 05:59:00PM +0300, Gena Makhomed wrote:<br>
<br>
> > Т.е. директории должны быть как бы зеркалами друг друга.<br>
> > <br>
> > Это возможно сделать?<br>
> <br>
> Теоретически - наверное возможно, если написать свой модуль ядра,<br>
> который будет реализовывать эту логику на уровне файловой системы.<br>
> <br>
<br>
кажется в лялихе тоже такое было.<br>
<br>
MOUNT_UNIONFS(8)        FreeBSD System Manager's Manual       MOUNT_UNIONFS(8)<br>
<br>
NAME<br>
     mount_unionfs — mount union file systems<br>
<br>
SYNOPSIS<br>
     mount_unionfs [-b] [-o options] directory uniondir<br>
<br>
DESCRIPTION<br>
     The mount_unionfs utility attaches directory above uniondir in such a way<br>
     that the contents of both directory trees remain visible.  By default,<br>
     directory becomes the upper layer and uniondir becomes the lower layer.<br>
<br>
     The options are as follows:<br>
<br>
     -b      Deprecated.  Use -o below instead.<br>
<br>
     -o      Options are specified with the -o flag followed by an option.<br>
             The following options are available:<br>
<br>
             below   Inverts the default position, so that directory becomes<br>
                     the lower layer and uniondir becomes the upper layer.<br>
                     However, uniondir remains the mount point.<br>
<br>
             copymode = traditional | transparent | masquerade<br>
                     Specifies the way to create a file or a directory in the<br>
                     upper layer automatically when needed.  The traditional<br>
                     mode uses the same way as the old unionfs for backward<br>
                     compatibility, and transparent duplicates the file and<br>
                     directory mode bits and the ownership in the lower layer<br>
                     to the created file in the upper layer.  For behavior of<br>
                     the masquerade mode, see MASQUERADE MODE below.<br>
<br>
             whiteout = always | whenneeded<br>
                     Specifies whether whiteouts should always be made in the<br>
                     upper layer when removing a file or directory or only<br>
                     when it already exists in the lower layer.<br>
<br>
             udir=mode<br>
                     Specifies directory mode bits in octal for masquerade<br>
                     mode.<br>
<br>
             ufile=mode<br>
                     Specifies file mode bits in octal for masquerade mode.<br>
<br>
             gid=gid<br>
                     Specifies group for masquerade mode.<br>
<br>
             uid=uid<br>
                     Specifies user for masquerade mode.<br>
<br>
     To enforce file system security, the user mounting a file system must be<br>
     superuser or else have write permission on the mounted-on directory.  In<br>
     addition, the vfs.usermount sysctl(8) variable must be set to 1 to permit<br>
     file system mounting by ordinary users.  However, note that transparent<br>
     and masquerade modes require vfs.usermount to be set to 0 because this<br>
     functionality can only be used by superusers.<br>
<br>
     Filenames are looked up in the upper layer and then in the lower layer.<br>
     If a directory is found in the lower layer, and there is no entry in the<br>
     upper layer, then a shadow directory will be created in the upper layer.<br>
     The ownership and the mode bits are set depending on the copymode option.<br>
     In traditional mode, it will be owned by the user who originally did the<br>
     union mount, with mode 0777 (“rwxrwxrwx”) modified by the umask in effect<br>
     at that time.<br>
<br>
     If a file exists in the upper layer then there is no way to access a file<br>
     with the same name in the lower layer.  If necessary, a combination of<br>
     loopback and union mounts can be made which will still allow the lower<br>
     files to be accessed by a different pathname.<br>
<br>
     Except in the case of a directory, access to an object is granted via the<br>
     normal file system access checks.  For directories, the current user must<br>
     have access to both the upper and lower directories (should they both<br>
     exist).<br>
<br>
     Requests to create or modify objects in uniondir are passed to the upper<br>
     layer with the exception of a few special cases.  An attempt to open for<br>
     writing a file which exists in the lower layer causes a copy of the<br>
     entire file to be made to the upper layer, and then for the upper layer<br>
     copy to be opened.  Similarly, an attempt to truncate a lower layer file<br>
     to zero length causes an empty file to be created in the upper layer.<br>
     Any other operation which would ultimately require modification to the<br>
     lower layer fails with EROFS.<br>
<br>
     The union file system manipulates the namespace, rather than individual<br>
     file systems.  The union operation applies recursively down the directory<br>
     tree now rooted at uniondir.  Thus any file systems which are mounted<br>
     under uniondir will take part in the union operation.  This differs from<br>
     the union option to mount(8) which only applies the union operation to<br>
     the mount point itself, and then only for lookups.<br>
<br>
______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></blockquote></div><br></div>