Re: XFS в ядрах серии 2.4

xfs это единственная рабочая журналируемая файловая система под линукс все остальное лажа... все кто хочет поспорить пусть покажет фс где есть квоты и списки доступа

Re: Re: XFS в ядрах серии 2.4

я конечно уважаю ваше мнение, но поспорю. я также очень
люблю xfs, но должен отметить, что все таки существует
"фс где есть квоты и списки доступа", это ext3.

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

не даром в rh enterprise именно ext3 используется,
потому что очень стабильно, а все-таки что бы не
говорили разные злобники, rh в свои enterprise говно
не сует.

---
всего хорошего.

Re: Re: XFS в ядрах серии 2.4

reiserfs+спец патчи, ext3+спец патчи

Re: XFS в ядрах серии 2.4

>xfs это единственная рабочая журналируемая файловая система под линукс все остальное лажа... все кто хочет поспорить пусть покажет фс где есть квоты и списки доступа

например reiserfs - использую на серверах последние лет 5 (начиная с 2.2 ядра) В то время, когда оно появилось другими журналируемыми FS вообще под линуксом не пахло, был правда ext3 но очень сырой и только под 2.4.

по _умолчанию_ квот там действительно нету, но если посмотреть на ftp.namesys.com, то там есть соответствующий патч. Почему они его не включают в основную ветку - для меня до сих пор загадка, т.к. работает он довольно хорошо и глюков в последние год - два за ним особо не замечал (до этого правда были при взаимодействии с knfsd)

по поводу ACL - ничего сказать не могу, т.к. данным делом не пользуюсь поскольку клиенты используют FS через NFS.

Re: XFS в ядрах серии 2.4

Т.е. в 2.4.25 он уже будет ?

Кстати, никто не знает FS где была бы квота на размер директории ?

Re:

>Кстати, никто не знает FS где была бы квота на размер директории ?

немного не понял вопроса ?? в смысле квота на размер директории?

Re: Re:

Это из категории "Странного хочется"
В Линукс ведь квота по пользователям/группам.
А хотелось бы задавать некий предел максимального размера для какой-либо директории для _всех_ пользователей имеющих право записи туда. Соответственно то же самое для другой директории.
Т.е. получить то же самое как если бы каждая директория была бы
на своем разделе жесткого диска. Пригодилось бы для поддержки виртуальных пользователей у которых системный UID одинаковый, а разграничение прав осуществляется пользовательским процессом.
Понятно, что задачу можно решить подругому. Но все-таки ?
С LVM связываться неохота.

Re: Re: Re:

>С LVM связываться неохота.

Тогда иди в жопу! :-)

Re: Re: Re: Re:

Ценю твой юмор, но LVM все же - изврат.
К тому же Линуксовые FS умеют лишь grow а вот с shrink у них
туго (и понятно почему). Можно решить задачу в userspace, но тогда
призагибе сервера (или каких либо неполадках) информация о
занятом/свободном месте в директории исказится. Понятно что ее можно восстановить, но вот устойчивость на уровне ядра было бы самое то.

Re:

>Понятно, что задачу можно решить подругому. Но все-таки ?

а частно это надо, есть смысл в этом?

Просто мы будем патчи делать к ядру, вот интерестно какие фитчи нужны?

>С LVM связываться неохота.

а что так ?

Re: Re: Re:

Если устроить так, что каждый квотируемый раздел будет иметь свою группу, то квота на эту группу будет работать должным образом.

Btw, а кто как поступает в ситуации, когда юзера, принадлежащие двум разным группам должны писать в один каталог. Ничего, кроме ввода
третьей "общей" группы и установки sgid на каталог как-то не придумывается...

Re: Re: Re: Re:

Ну тут то все ясно - ACL В man на XFS ACL похожий примерчик
рассмотрен.

Re: Re:

>>Понятно, что задачу можно решить подругому. Но все-таки ?
>а частно это надо, есть смысл в этом?
>Просто мы будем патчи делать к ядру, вот интерестно какие фитчи нужны?

Задачу, как всегда можно решать различными способами.
Для меня ценно универсальное решение.
Вообще виртуальные пользователи и как следствие механизмы
аутентификации/авторизации в userspace (т.е. в пользовательских
приложениях) делаются не от хорошей жизни.

В VFS нуна поковырять.


>>С LVM связываться неохота.
>а что так ?
Я уже писал LVM сама по себе штука не плохая,
но главное - поддержка фаловой системой (которая работает "Поверх" LVM)
Увеличения размера aka Grow (с этим проще) и уменьшения размера
aka Shrink (а с этим труба).
И к тому же хранить каждую директорию на своем томе это ....
это.. не очень правильно (как минимум).

Re: Re: Re: Re: Re:

Дык, понятное дело, что c ACL. Но вот пример, что не дает мне покоя: создаем каталог dir/ даем на него # setacl -m g:writer1:rwx dir # setacl -m d:g:writer1:rwx dir ... ну и для группы writer2 то же самое идем юзером из любой из этих групп и пишем файл. Какова будет группа (основная) у этого файла? - правильно, primary group писателя. А она у меня, например, everyone и права на нее должны быть rwx. Выходит, что реальные права на файл будут у writer2, writer2 _И_ everyone. Если использовать sgid (н-р. на writer1), то все будет хорошо, пока юзер из writer2 не создаст каталог (sgid не унаследуется).

Re: Re: Re: Re: Re:

Дык, понятное дело, что c ACL. Но вот пример, что не дает мне покоя:
создаем каталог dir/
даем на него
# setacl -m g:writer1:rwx dir
# setacl -m d:g:writer1:rwx dir
... ну и для группы writer2 то же самое
идем юзером из любой из этих групп и пишем файл. Какова будет группа
(основная) у этого файла? - правильно, primary group писателя. А она у
меня, например, everyone и права на нее должны быть rwx. Выходит, что
реальные права на файл будут у writer2, writer2 _И_ everyone. Если использовать sgid (н-р. на writer1), то все будет хорошо, пока юзер из
writer2 не создаст каталог (sgid не унаследуется).

Re: Re: Re: Re: Re: Re:

Похоже без общей группы таки не обойтись

Re: Re: Re: Re: Re: Re: Re:

Довольно таки неудобно :-( Хотя, жить можно.

Re: Re: Re:

А чем плохо создать при помощи dd файлики нужных размеров, отформатировать их и mount'ом присобачить в нужные каталоги?

Re: XFS в ядрах серии 2.4

извините это в каком же ядре есть xfs???