нескольо simlink'ов на один каталог, возможно?

Как два пальца об асфальт.
А в чем собственно проблема?

Тоже сначала так подумал, но потом вопрос дочитал. Товарищ, похоже, смержить хочет.

Нет такого, afaik. Можно создать катлог и в него наложить симлинков, т.е. всё будет в подкаталогах. Но не так, чтобы все файлы сразу в одном.

Нет. Гуглите: unionfs, aufs, mhddfs.

unionfs, aufs, mhddfs

разве они смогут объединить несколько каталогов, скажем, в хомяке?

mhddFS может

Что это?

нетривиально. Надо как-то разруливать ситуацию с одинаковыми именами файлов.

mhddFS может

Спасибо! Получилось.

Fuse-прослойка для объединения каталогов

man 'mount -o bind'

man 'mount -o bind'

И как ты несколько каталогов в один так примонтируешь?

Если монтировать до входа в систему, почему нет?

когда-то делал именно через mount -o bind с дополнительными опциями - нужно было для обеспечения надежности через то самое место.

да похоже mhddfs это то,что нужно, чтобы в последствии можно было разделы подмонтировать к своим точкам если понадобится.

вечером попробую

А что за опции, хоть примерно? А то без них должна быть та же проблема, что с симлинками, каждый следующий целиком перекрывает предыдущий.

Unionfs, еще есть что-то работающее через fuse, название только забыл.

вот вроде оно

 The shared subtrees operations.
              Since  Linux  2.6.15 it is possible to mark a mount and its submounts as shared, private, slave or unbindable. A
              shared mount provides ability to create mirrors of that mount such that mounts and umounts  within  any  of  the
              mirrors  propagate  to  the  other mirror. A slave mount receives propagation from its master, but any not vice-
              versa.  A private mount carries no propagation abilities.  A unbindable mount is a private mount which cannot be
              cloned through a bind operation. Detailed semantics is documented in Documentation/filesystems/sharedsubtree.txt
              file in the kernel source tree.

              Supported operations:
                     mount --make-shared mountpoint
                     mount --make-slave mountpoint
                     mount --make-private mountpoint
                     mount --make-unbindable mountpoint

              The following commands allows one to recursively change the type of all the mounts under a given mountpoint.

                     mount --make-rshared mountpoint
                     mount --make-rslave mountpoint
                     mount --make-rprivate mountpoint
                     mount --make-runbindable mountpoint

собственно сабж, возможно ли сделать несколько симлиноков с разных каталогов, на 1, чтобы содержимое всех каталогов было в 1 папочке (симлинки со всех файлов в каталогах не предлагать)

NoWay Делить на ноль нельзя.

man 'mount -o bind'

можно. Но получится ОДИН каталог. А ввот ТС хочет, что-бы каталоги были одновременно

1. РАЗНЫЕ

2. ВСЕ В ОДНОМ

Это классические взаимоисключающее параграфы. Решаются путём создания лишней сущности, как выше сказали — прослойки вроде unionFS.

всем спасибо, меня полностью устроил mhddfs, посмотрим со временем как оно будет грузить проц.. если что попробую еще aufs, оно вроде как на уровне ядра и должно более шустро работать.

Судя по нагугленному, все про propagation там относится к отображению точек монтирования. Получалось именно слить содержимое двух каталогов в один? Например:

$ ls first_dir
a  b

$ ls second_dir
c  d

$ ls merged_dir
a  b  c  d

более того, еще и реплицировало файлы с одного в другой и обратно

Получалось именно слить содержимое двух каталогов в один?

что вы под этим имели ввиду?

mhddfs работает именно так... но данные хранятся в разных разделах (целиком) и мапятся в точку монтирования.

$ ls first_dir
a  b

$ ls second_dir
c  d

$ ls merged_dir
a  b  c  d

Получалось именно слить содержимое двух каталогов в один?

видимо я сначала не правильно понял.. вы имели ввиду 2 каталога с одинаковым именем на разных разделах?.. не пробовал у меня все имена каталогов индивидуальны

если что попробую еще aufs, оно вроде как на уровне ядра и должно более шустро работать

оно шустро работает, я пробовал(в slax'е). Но чудес не бывает. ИМХО такие прокладки не нужны.

PS: попробуй aufs, тебе понравится. Ещё не забудь здесь почитать.

видимо я сначала не правильно понял.. вы имели ввиду 2 каталога с одинаковым именем на разных разделах?.. не пробовал у меня все имена каталогов индивидуальны

Тут вопрос туманный, это да. Имена каталогов разные (как в примере), и раздел неважно, один или разные. То есть то же, что делает mhddfs или aufs, только без них, с помощью только mount'a. Выше вон утверждают что это возможно, а я не пойму как.

ИМХО такие прокладки не нужны.

Нужны, ибо дают возможность держать всё с носителя в ro и только измененную часть в rw. Для embedded и всяких лайвов пригождается. Другое дело что сабжевый вопрос, наверное, можно было бы и без них решить.

Чудеса...

Нужны, ибо дают возможность держать всё с носителя в ro и только измененную часть в rw. Для embedded и всяких лайвов пригождается.

да, с этим я согласен.

вполне можно, собственно нужно мне это было для того чтобы на торрентопомойке не следить за местом.. всего 4 винта по 1Тб.. и постоянно заканчивается место на каком то разделе.. приходится что то переносить,что-то удалять... я их таким образом объеденил в «облако»)) назовем это так.. и оно само рулит куда кидать данные,а мне не принципиально где в итоге окажется файл.

«Без них» в смысле без дополнительных ФС. Как это можно сделать мне пока неясно.

А насчет само рулит, это кто именно так умеет? В смысле кидать туда, где больше свободного места, если правильно понял.

В смысле кидать туда, где больше свободного места, если правильно понял.

на офф.сайте и вики написано примерно следующее:

Если на первом диске свободного места достаточно, т.е. не меньше значения mlimit из опций mhddfs (которое по умолчанию равно четырём гигабайтам) - файл будет создан там. Если места меньше, чем mlimit - файл будет создан на втором диске. Если и на нём места мало - файл будет создан на третьем диске. Если же на каждом из трёх дисков свободного места меньше, чем значение mlimit, будет выбран просто-напросто диск, где свободного места осталось больше всего.

Но это ещё не всё. Если какой-то из дисков исчерпает своё свободное пространство в процессе записи файла, запись не “обвалится”; mhddfs обойдёт эту неприятность абсолютно прозрачно, переместив уже записанные данные файла на другой диск (где места побольше) и продолжив дописывать последующие данные уже туда. Приложение, записывающее файл, ничего и не заметит (кроме, может быть, небольшой задержки при записи очередной порции данных).

Ого, круто. Спасибо!

а если бы ты сразу сказал про торрентопомойку и четыре диска, можно было тебя сразу матючьями покрыть за незнание lvm

порошок уходи