>>
>>В догонку - кто будет выделять inode number (в случае люстры fid
>>number) - клиент/сервер?
>
>Здесь иной подход: номера инод не синхронизируются с сервером и между клиентами,
>вместо этого сипользуется полный путь. Поэтому нет необходимости в кривом open_by_inode/open_by_cookie
>как в nfs и без проблем с перемещенными объектами. что-то мне говорит что это будет тормоз при любых операциях связаных с metadata.
ибо nfs кэширует открытый файл и через куки находит ее, а так при каждой операции записи надо будет делать преобразование имя -> inode.
Я не прав ?
я так же не пойму где в вашей схеме место generation у inode. путь не изменился - а данные там уже другие.
Примерно вот такой test case:
>>>>>>>>>
cp -f /bin/bash $DIR1/$tdir/bash
/bin/sh -c 'sleep 1; rm -f $DIR2/$tdir/bash; cp /bin/bash $DIR2/$tdir' &
err=$($DIR1/$tdir/bash -c 'sleep 2; openfile -f O_RDONLY /proc/$$/exe >& /dev/null; echo $?')
>>>>>>>>>>>>
>
>>Еще такой забавный набор флагов у open -
>>open(,O_RW|O_CREATE|O_TRUNCATE).
>>замете надо это сделать атомарно, а не как 2-3 последовательных команды.
>
>Для транзакции (open intent) существует набор флагов, передаваемый на сервер, там они
>используются как аргумент для open/mkdir и т.д.
дело в том что truncate может быть сделан с другой ноды, и create с другой ноды.
а глобального семафора как в случае VFS - не будет, или если будет - будут тормоза.
я не увидел ответа на счет работы транзакций и replay у журнала транзакций, и коментарий на счет пседво-sync_io в случае записи с разных клиентов в пределы страницы.
можно немного пояснений?
