Многоуровневая иерархическая файловая система это: Файловая система (8 класс) Информатика и ИКТ

Содержание

с ее помощью организуется многоуровневая иерархическая файловая система что это

Коля Иванов для подбора пароля использует компьютерную программу, осуществляющую перебор пароля по словарю. В словаре содержится 100 слов, программа-в … зломщик перебирает 1000 паролей в секунду. Коля знает, что подбираемый пароль состоит из одного, двух или трех слов из словаря, записанных последовательно (без дополнительных символов между ними). Слова в последовательности могут повторяться. Из приведенных вариантов Выберете минимальное время, которое потребуется Коле, чтобы гарантированно успеть подобрать пароль. Выберите один ответ: . o20 минут О 40 минут о 10 минут o30 МИНУТ​

Напишите программу, отчасти имитирующую работу кассового аппарата: вводятся цены покупаемых товаров, нужно вывести общую стоимость товаров. Но не всё … так просто: сейчас в магазине действует акция – на каждый товар, стоимость которого больше 1500, действует скидка в 8%. Не забудьте это учесть при написании программы.

Люди, помогите найти ошибку пожалуйста! задача (Python): Количество различных элементов — 2 Дан список. Посчитайте, сколько в нём различных элементов, … не изменяя самого списка. Входные данные: Вводится список чисел. Все числа списка находятся на одной строке. Все числа целые неотрицательные и не больше 1000. Выходные данные: Выведите ответ на задачу. Мой вариант решения: e = list(map(int, input().split())) count = 1 r = [] for i in range (len(e)): c = 0 for j in range (len(r)): if e[i] == r[j]: c+=1 if c == 0 and j + 1 == len(r): count += 1 r.append(e[i]) print(count) (выдает "программа выполнялась слишком долго и была прервана")

238 перевести в двоичную систему

Нужна помощь с задачей c++ (надо только ifы сделать) Нечетные числа Нужно вывести на экран нечетные чисел из отрезка от A до B. #include using namespa … ce std; int main() { int a,b; cin»a»b; for(int i=a; i<=b; i++) { if (здесь) { if(и здесь тоже) cout«i; else { if (условие ) cout«i; else cout«i«" "; } } } return 0; }

Решите пожалуйста все правильно даю много баллов

Помогите люди добрые, Нужно ответить на этот вопрос. Виртуальная реальность приходит в гейм-индустрию

Помогите срочно!!!!!!

Помогите срочно !!!!!!!!

Помогите пожалуйста с Паскалем , Информатика

Файлы и файловая система. Информатика 7 класс

1. Файлы и файловая система

Информатика 7 класс

2. Что такое файл?

Файл (от англ.слова file - досье, набор
документов) - это программа или
данные, имеющие имя и
хранящиеся в долговременной
памяти компьютера

3. Имя файла

состоит из двух частей, разделенных
точкой: имени файла (до 255 символов) и
расширения (3 символа) .
Расширение указывает на тип файла, или
какого типа информация хранится в файле.
Собственное имя файлу дает пользователь, тип
файла обычно задается автоматически.
Пример:
proba.txt

4. Расширения файлов

txt,
doc (текстовые файлы)
bmp, gif, jpg (графические файлы)
wav, mid (звуковые файлы)
аvi (видеофайлы)
bas, pas (программы на языках
программирования)
exe, com (исполняемые файлы)

5. Символы, которые не используют при задании имени файла

/\*:?|“

6. Что такое файловая система?

Файловая система - это система
хранения файлов и организация
каталогов
В операционной
системе Windows
вместо каталогов
используется понятие
«папка».
Папка – это объект
Windows,
предназначенное для
объединения файлов и
других папок в группы.

7. Одноуровневая файловая система

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

8. Многоуровневая иерархическая файловая система

Представляет собой систему вложенных
папок. В каждой папке могут храниться папки
нижнего уровня и файлы.
Каждый
диск имеет логическое имя,
обозначаемое латинской буквой с двоеточием:
А:, В: - гибкие диски; С: - жесткий диск; D:, Е: лазерные диски.
Папкой верхнего уровня для диска является
корневая папка (или корневой каталог), которая
обозначается с добавлением знака \.
Например: А:\

10. Пример

В коревом каталоге диска А: имеются две
вложенные папки 1-го уровня (Документы и
Изображения), а в папке Изображения – одна
вложенная папка 2-го уровня (Фото). При этом
в папке Документы имеется файл
Сочинение.doc, а в папке Фото – файл
Класс.bmp
А:\
Документы
Сочинение.doc
Изображения
Фото
Класс.bmp

11. Путь к файлу

Начинается с логического имени диска, затем
записывается последовательность имен вложенных друг в
друга папок, в последней из которых содержится нужный
файл. Имена дисков записываются через разделитель «\».
Путь к файлу вместе с
именем файла называют
полным именем файла.
C:\Рефераты\Физика\Оптические явления.doc
C:\Рефераты\Информатика\Интернет.doc
C:\Рефераты\Информатика\Компьютерные вирусы.doc
C:\Рисунки\Закат.jpg
C:\Рисунки\ Зима.jpg

12. Операции с файлами

Копирование
Перемещение
Удаление
Переименование

13. Архивация файлов

Для
долговременного хранения или
передачи файлов по компьютерным сетям
целесообразно уменьшать объем файлов –
то есть архивировать
Для проведения архивации используются
специальные программы – архиваторы
(WinRAR, WinZIP и др.)

14. Запишите полные имена всех файлов

15. Запишите полные имена всех файлов

C:\Мои документы\Иванов\QBasic.doc
C:\Мои документы\Петров\Письмо.txt
C:\Мои документы\Петров\Рисунки\Море.bmp
C:\Фильмы\Интересный фильм.avi

16. Постройте дерево каталогов

C:\Рисунки\Природа\Небо.bmp
C:\Рисунки\Природа\Снег.bmp
C:\Рисунки\Компьютер\Монитор.bmp
C:\Мои документы\Ученики\11 класс\
Долголенко А.Э\ Доклад.doc
Проверка:
Локальный
диск С:
Мои документы
Ученики
Мои рисунки
Компьютер
11 класс
Монитор.bmp
Долголенко А.Э
Доклад.doc
Природа
Небо.bmp
Снег.bmp
составить
схему
многоуровневой файловой
системы Рабочий стол
(оформить на альбомном
листе)

Файлы и файловая система - презентация онлайн

1. Файлы и файловая система

2. Характеристики файла

Характеристики файла
имя
название
Например:
размер
расширение
время
создания
обозначение
(значок)

3. Имя файла

Имя файла состоит из двух частей, разделенных
точкой:
–название файла (задает пользователь)
–расширение, определяющее тип хранимой
информации (программа, данные и т.д.) (обычно
задается программой автоматически при его
создании).
Документ.doc
Название файла расширение
Пример:
proba.txt
Измерения информации.doc
Тип файла
Расширение
Исполняемые
программы
exe, com
Текстовые файлы
txt, rtf, doc
Графические файлы
bmp, gif, jpg, png, pds, wmf
Web-страницы
htm, html
Звуковые файлы
wav, mp3, midi, kar, ogg
Видеофайлы
avi, mpeg, vob
Код (текст) программы
на языках
программирования
bas, pas, cpp
Анимационные
gif, swf
Архивные
rar, zip, arj, 7z

5. Соглашение 8.3

До появления операционной
системы Windows 95 на
большинстве компьютеров IBM
PC работала операционная
система MS-DOS, в которой
действовали весьма строгие
правила присвоения имен
файлам.
Эти правила называют соглашением 8.3:
1)
2)
По соглашению 8.3 имя файла может состоять из двух частей,
разделенных точкой. Первая часть может иметь длину до 8
символов, а вторая часть (после точки) — до 3 символов. Вторая
часть, стоящая после точки, называется расширением имени.
При записи имени файла разрешается использовать только буквы
английского алфавита и цифры. Начинаться имя должно с буквы.
Пробелы и знаки препинания не допускаются, за исключением
восклицательного знака (!), тильды (~) и символа подчеркивания
(_).

6. Длинные имена файлов

После введения в действие операционной системы
Windows 95 требования к именам файлов стали
существенно мягче.
Они действуют и во всех последующих версия
операционных систем Windows:
1) Разрешается использовать до 255 символов.
2) Разрешается использовать символы национальных
алфавитов, в частности русского.
3) Разрешается использовать пробелы и другие ранее
запрещенные символы, за исключением следующих девяти:
/\:*?"|.
4) В имени файла можно использовать несколько точек.
Расширением имени считаются все символы, стоящие за
последней точкой.

7. Файловая система

На каждом носителе информации (гибком,
жестком или лазерном диске) может
храниться большое количество файлов.
Порядок хранения файлов на диске
определяется установленной файловой
системой.
Файловая система - это система хранения
файлов и организации каталогов.

8. Файловая система

Файловая система – это совокупность
файлов и папок и взаимосвязи между
ними.
Различают одноуровневую файловую
систему (например, файлы на дискете или
флеш-карте) и многоуровневую,
имеющую уровни вложенности
(иерархическую).

9. Одноуровневая файловая система

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

10. Многоуровневая иерархическая файловая система

Если на диске хранятся сотни и тысячи файлов, то
для удобства поиска файлы организуются в
многоуровневую иерархическую файловую
систему, которая имеет «древовидную» структуру
(имеет вид перевернутого дерева).

11. Многоуровневая файловая система

12. Корневой каталог

Главный каталог диска называется корневым
каталогом или «корнем» диска (его пользователь видит,
«открыв» диск, например, в Проводнике Windows или
аналогичной программе). Он является каталогом самого
верхнего уровня.
Он обозначается буквой логического диска, за которой
следует двоеточие и знак «\» (обратный слэш).
Например:
С:\ – это обозначение корневого каталога диска С

13. Папка

В операционной системе Windows вместо
каталогов используется понятие «папка».
Папка – это объект Windows, предназначенный для
объединения файлов и других папок в группы.
Понятие папки шире, чем понятие «каталог».
В Windows на вершине иерархии папок находится
папка Рабочий стол. Следующий уровень
представлен папками Мой компьютер, Корзина
и Сетевое окружение (если компьютер
подключен к локальной сети).

14. Иерархии папок Windows

15. Путь к файлу

Для того чтобы найти файл в иерархической файловой структуре,
необходимо указать путь к файлу. В путь к файлу входят
записываемые через разделитель "\" логическое имя диска и
последовательность имен вложенных друг в друга каталогов, в
последнем из которых находится данный нужный файл.
C:\Рефераты\
C:\Рефераты\Физика\
C:\Рефераты\Информатика\
C:\Рисунки\

16. Полное имя каталога

– это перечисление каталогов, в которые нужно войти,
чтобы попасть в этот каталог (начиная с корневого
каталога диска)
C:\Рефераты
C:\Рефераты\Физика
C:\Рефераты\Информатика
C:\Рисунки

17. Полное имя файла

Путь к файлу вместе с именем файла называют
полным именем файла.
C:\Рефераты\Физика\Оптические явления.doc
C:\Рефераты\Информатика\Интернет.doc
C:\Рефераты\Информатика\Компьютерные вирусы.doc
C:\Рисунки\Закат.jpg
C:\Рисунки\ Зима.jpg
Задание 1.
Запишите полные имена всех
файлов
C:\Мои документы\Иванов\QBasic.exe
C:\Мои документы\Петров\Письмо.txt
C:\Мои документы\Петров\Рисунки\Море.bmp
C:\Фильмы\Интересный фильм.avi

19. Задание 2. Изобразите структуру файловой системы в виде дерева

C:\Рисунки\Природа\Небо.bmp
C:\Рисунки\Природа\Снег.bmp
C:\Рисунки\Компьютер\Монитор.bmp
C:\Мои документы\Доклад.doc

20. Задание 3.

В некотором каталоге хранился файл Дневник.txt.
После того, как в этом каталоге создали подкаталог и
переместили в созданный подкаталог файл
Дневник.txt, полное имя файла стало
A:\ SCHOOL \ USER \ TXT \ MAY \ Дневник.txt
Каково полное имя каталога, в котором хранился
файл до перемещения?
1) MAY
2) A: \ SCHOOL \ USER \ TXT
3) TXT
4) A: \ SCHOOL \ USER \ TXT \ MAY

21. Задание 110 из РТ

Пользователь работал с каталогом
Б:\ ДОКУМЕНТЫ \ ФОТО \ 2011 \ ВЕСНА.
Сначала он поднялся на три уровня вверх, потом спустился
в каталог ЭКЗАМЕН и после этого спустился в каталог
ИНФОРМАТИКА.
Укажите полный путь для того каталога, в котором
оказался пользователь (запишите номер правильного
ответа):
1)
Б:\ ДОКУМЕНТЫ \ ФОТО \ ИНФОРМАТИКА
2)
Б:\ ДОКУМЕНТЫ \ ИНФОРМАТИКА \ ЭКЗАМЕН
3)
Б:\ ДОКУМЕНТЫ\ ЭКЗАМЕН \ ИНФОРМАТИКА
4)
Б:\ДОКУМЕНТЫ\ФОТО\2011\ВЕСНА\ЭКЗАМЕН\ ИНФОРМАТИКА
Домашнее задание №12
1) Читайте в учебнике §2.3.1 - 2.3.2
2) Выполните письменно в тетради задания
№106-109,111-114 из Рабочей тетради
3) Закончите высказывание – определение
файла:
________ для данных на _______ памяти,
внутри которой хранится двоичный код
__________________ называется файлом.

Тест

ТЕСТ - "Файловые системы"

Выберите правильный ответ

1. Файл - это … a) программа или данные, хранящиеся в долговременной памяти. b) программа или данные, имеющие имя и хранящиеся в оперативной памяти. c) программа или данные, имеющие имя и хранящиеся в долговременной памяти. 2. Путь к файлу … a) начинается с логического имени диска, затем записывается последовательность имён вложенных друг в друга папок, в последней из которых находится нужный файл. b) начинается с последней папки, в которой находится нужный файл, затем записывается логическое имя диска. c) начинается с логического имени диска, затем записывается нужный файл, затем последовательность имён вложенных друг в друга папок. 3. В операционной системе Windows имя файла может иметь длину до … символов. a) 255 b) 256 c) 512 4. Имя файла состоит из двух частей: … a) имени и адреса первого сектора. b) имени и расширения. c) адреса первого сектора и объёма файла. 5. Расширение файлу присваивает … a) операционная система. b) процессор. c) программа при его создании. 6. Одноуровневая файловая система … a) когда каталог диска представляет собой линейную последовательность имён файлов и соответствующих начальных секторов. b) каталог диска представляет собой геометрическую последовательность имён файлов. c) каталог диска представляет собой иерархическую последовательность имён файлов. 7. Выберите правильное имя файла. a) 3:LIST.EXE b) 12345.BMP c) IN3:.TXT 8. Как правильно записывается путь к файлу? a) C:\Program\GAMES\CHESS\ b) C:/Program/GAMES/CHESS/ c) C::\Program\GAMES\CHESS\ 9. В файловой системе FAT длина имен ограничивалась … a) 32 символов - имя, 4 символа - расширение имени b) 16 символов - имя, 6 символа - расширение имени c) 8 символов - имя, 3 символа - расширение имени 10. На какие две области разбивается диск? a) область хранения файлов и файлы b) область хранения файлов и каталог c) системные и пользовательские диски 11. Что не является функцией файловой системы? a) удаление файлов, каталогов b) чтение информации из файлов c) передача файлов 12. Если на диске хранятся сотни и тысячи файлов, то для удобства поиска используется … a) многоуровневая иерархическая файловая система. b) одноуровневая файловая система. c) пятиуровневая файловая система. 13. В процессе форматирования диск разбивается на две области: … a) оперативную и кэш-память. b) область хранения и каталог. c) сектора и дорожки. 14. В процессе загрузки операционной системы происходит: … a) копирование файлов операционной системы с гибкого диска на жёсткий диск. b) копирование файлов операционной системы с CD – диска на жёсткий диск. c) последовательная загрузка файлов операционной системы в оперативную память. 15. Для организации доступа к файлам операционная система должна иметь сведения о … a) количестве файлов на диске. b) номерах кластера, где размещается каждый файл. c) содержании файла. 16. Где хранится выполняемая в данный момент программа и обрабатываемые данные? a) на устройстве вывода b) во внешней памяти c) в оперативной памяти 17. Каталогом называется место на диске имя и содержащее … a) информацию о файлах (имя, расширение, дата последнего обновления). b) список программ, составленных пользователем. c) только определённые файлы. 18. Имя логического диска обозначается … a) русскими буквами. b) латинскими буквами. c) буквами и цифрами. 19. Путь к файлу не включает … a) команду. b) имя каталога. c) имя диска. 20. Состояние операционной системы, при котором она перестает выдавать результаты и реагировать на запросы - это … a) отключение принтера. b) зацикливание. c) зависание.

Ваш результат : правильные ответы из 20 вопросов.

Презентация на тему: Иерархическая файловая система

КАТАЛОГИ

Каждый том носителя информации содержит корневой каталог, в котором перечислены хранящиеся на носителе файлы и папки.

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

Имя файла

Адрес первого

Объем

Дата

Время

Атрибуты

 

кластера

файла

создания

создания

 

 

 

(Кбайт)

 

 

 

Файл_1

34

2

14.01.2006

14.29

ar

Файл_2

36

1

20.03.2006

19.45

hs

Если на диске хранится много файлов, то для удобства поиска файлы хранятся в многоуровневой иерархической

файловой системе, которая имеет древовидную структуру.

Путь к файлу начинается с логического имени диска, затем записывается последовательность имен вложенных друг в друга папок, в последней из которых содержится нужный файл. Имена диска и папок записываются через разделитель «\».

А:\Документы\Изображения\image.bmp

Для восстановления файловой системы используются специальные программы. В ОС Windows - это программа Проверка дисков.

ДЕФРАГМЕНТАЦИЯ ДИСКОВ

Фрагментация файлов – фрагменты файла хранятся в различных, удаленных друг от друга кластерах.

В результате фрагментации файлов может происходить замедление скорости обмена данными с носителем информации.

Рекомендуется периодически проводить дефрагментацию диска, в процессе которой файлы записываются в кластеры, последовательно идущие друг за другом.

КОМПЬЮТЕРНЫЙ ПРАКТИКУМ

1. Проверка файловой системы диска

Вкладка Сервис

Если задан режим исправления ошибок файловой системы и восстановления поврежденных секторов, данный диск во время проверки нельзя использовать. Если какие-либо файлы используются, появится сообщение с просьбой отложить проверку до следующего запуска компьютера.

КОМПЬЮТЕРНЫЙ ПРАКТИКУМ

2. Дефрагментация диска

Дефрагментация диска

Анализ диска после дефрагментации

ФАЙЛЫ И ФАЙЛОВАЯ СИСТЕМА — презентация на Slide-Share.ru 🎓

1

Первый слайд презентации: ФАЙЛЫ И ФАЙЛОВАЯ СИСТЕМА

Понятие файла, файловой системы, классификация

Изображение слайда

2

Слайд 2

Назовите виды программного обеспечения Системное ПО Системы программирования Прикладное ПО

Изображение слайда

3

Слайд 3

Программное обеспечение – вся _______________________, хранящихся на всех устройствах ____________________________ компьютера. совокупность программ долговременной памяти

Изображение слайда

4

Слайд 4

Операционная система – набор ___________, управляющих __________________________ и внешними устройствами и ведущих ____________ с пользователем. программ ОЗУ, процессором, файлами диалог

Изображение слайда

5

Слайд 5: Что такое файл?

Все программы и данные хранятся в долговременной (внешней) памяти компьютера в виде файлов. Файл — это информация, хранящаяся на внешнем носителе и объединенная общим именем.

Изображение слайда

6

Слайд 6: Файловая система

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

Изображение слайда

7

Слайд 7

Полное имя файла Поиск файла Адрес Диск: \ путь Имя файла Имя.расширение Как найти нужный файл?

Изображение слайда

8

Слайд 8: Имя файла

Имя файла состоит из двух частей, разделенных точкой: собственно имя файла (до 255 символов) и расширения (3 символа). Собственно имя файлу дает пользователь, а тип файла обычно задается программой автоматически при его создании. Расширение указывает, какого рода информация хранится в файле, тип файла proba. txt Имя файла Расширение

Изображение слайда

9

Слайд 9: Соглашение 8.3

Имя файла может состоять из двух частей, разделенных точкой. Первая часть может иметь длину до 8 символов. При записи имени файла разрешается использовать только буквы английского алфавита и цифры. Начинаться имя должно с буквы. Пробелы и знаки препинания не допускаются, за исключением восклицательного знака (!), тильды ( ~ ) и символа подчеркивания (_).

Изображение слайда

10

Слайд 10: Длинные имена файлов

1. Разрешается использовать до 255 символов. 2. Разрешается использовать символы национальных алфавитов, в частности русского. 3. Разрешается использовать пробелы и другие ранее запрещенные символы, за исключением следующих девяти: / \ : * ? "< >| 4. В имени файла можно использовать несколько точек. Расширением имени считаются все символы, стоящие за последней точкой.

Изображение слайда

11

Слайд 11: Символы, которые не используют при задании имени файла

/ \ * : ? | “ < >

Изображение слайда

12

Слайд 12

ФАЙЛЫ Исполняемые (программы) Инициализация (запуск) Архивные файлы Может храниться любая информация Файлы данных Просмотр, редактирование

Изображение слайда

13

Слайд 13

Тип файла Расширение Исполняемые программы exe, com, bat Текстовые файлы txt, rtf, doc Графические файлы bmp, gif, jpg, png, pds Web-страницы htm, html Звуковые файлы wav, mp3, midi, kar, ogg Видеофайлы avi, mpeg Код (текст) программы на языках программирования bas, pas, cpp Архивные файлы arj, zip, rar

Изображение слайда

14

Слайд 14: Папка ( каталог) – совокупность файлов (подкаталогов) по одной тематике

В операционной системе Windows вместо каталогов используется понятие «папка». Папка – это объект Windows, предназначенное для объединения файлов и других папок в группы. Понятие папки шире, чем понятие «каталог». В Windows на вершине иерархии папок находится папка Рабочий стол. (Следующий уровень представлен папками Мой компьютер, Корзина и Сетевое окружение (если компьютер подключен к локальной сети).

Изображение слайда

15

Слайд 15

На одном компьютере может быть несколько дисков. Каждому дисководу присваивается однобуквенное имя после : А:, В:, С:, D :, … Логический диск – это физический диск, реальный диск или часть физического диска, которому присвоено имя.

Изображение слайда

16

Слайд 16: Файловая структура – вся совокупность файлов на диске и взаимосвязей между ними

Одноуровневая Многоуровневая (иерархическая)

Изображение слайда

17

Слайд 17: Одноуровневая файловая система

Для дисков с небольшим количеством файлов (до нескольких десятков) удобно применять одноуровневую файловую систему, когда каталог (оглавление диска) представляет собой линейную последовательность имен файлов. Для отыскания файла на диске достаточно указать лишь имя файла. Диск: имя.расширение А: tetris.exe

Изображение слайда

18

Слайд 18: Многоуровневая иерархическая файловая система

Если на диске хранятся сотни и тысячи файлов, то для удобства поиска файлы организуются в многоуровневую иерархическую файловую систему, которая имеет «древовидную» структуру (имеет вид перевернутого дерева). Диск ( корневой каталог) \ каталог \ … \ имя.расширение

Изображение слайда

19

Слайд 19: Путь к файлу – последовательность папок, начиная от самой верхней и заканчивая той, в которой непосредственно хранится файл

Для того чтобы найти файл в иерархической файловой структуре необходимо указать путь к файлу. В путь к файлу входят записываемые через разделитель "\" логическое имя диска и последовательность имен вложенных друг в друга каталогов, в последнем из которых находится данный нужный файл. C:\Рефераты\ C:\Рефераты\Физика\ C:\Рефераты\Информатика\ C:\Рисунки\ Полное имя файла – имя логического диска + путь к файлу + имя файла

Изображение слайда

20

Слайд 20

Путь к файлу вместе с именем файла называют полным именем файла. C:\Рефераты\Физика\Оптические явления. doc C:\Рефераты\Информатика\Интернет. doc C:\Рефераты\Информатика\Компьютерные вирусы. doc C:\Рисунки\Закат. jpg C:\Рисунки\ Зима. jpg

Изображение слайда

21

Слайд 21: Иерархии папок Windows

Изображение слайда

22

Последний слайд презентации: ФАЙЛЫ И ФАЙЛОВАЯ СИСТЕМА: Операции с файлами и папками

Копирование (копия файла помещается в другой каталог) Перемещение (сам файл перемещается в другой каталог) Удаление (запись о файле удаляется из каталога) Переименование (изменяется имя файла).

Изображение слайда

Задание №4 Файловая система — презентация на Slide-Share.ru 🎓

1

Первый слайд презентации

Задание №4 Файловая система

Изображение слайда

2

Слайд 2: Что такое файл?

Все программы и данные хранятся в долговременной (внешней) памяти компьютера в виде файлов. Файл — это определенное количество информации (программа или данные), имеющее имя и хранящееся в долговременной (внешней) памяти.

Изображение слайда

3

Слайд 3: Имя файла

Имя файла состоит из двух частей, разделенных точкой: собственно имя файла и расширение, определяющее его тип (программа, данные некоторого типа и т.д.). Собственно имя файлу дает пользователь, а расширение файла обычно задается программой автоматически при его создании. Пример: proba. txt Единицы измерения информации. doc

Изображение слайда

4

Слайд 4

Каталог - специальное место на диске, в котором хранятся имена файлов, сведения об их объеме, времени их создания или обновления.

Изображение слайда

5

Слайд 5: Файловая система

На каждом носителе информации (жестком, оптическом диске или flash носителях) может храниться большое количество файлов. Порядок хранения файлов на диске определяется установленной файловой системой. Файловая система - это система хранения файлов и организации каталогов, это совокупность файлов и взаимосвязей между ними на внешних носителях.

Изображение слайда

6

Слайд 6

Различают два вида организации файловой структуры: одноуровневую и многоуровневую.

Изображение слайда

7

Слайд 7: Одноуровневая файловая система

Для дисков с небольшим количеством файлов (до нескольких десятков) удобно применять одноуровневую файловую систему, когда каталог (оглавление диска) представляет собой линейную последовательность имен файлов. Для отыскания файла на диске достаточно указать лишь имя файла. A : tetris.exe Диск: имя.расширение

Изображение слайда

8

Слайд 8: Многоуровневая иерархическая файловая система

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

Изображение слайда

9

Слайд 9

В Windows каждый диск или логический раздел диска имеют логическое имя, которое обозначается буквой латинского алфавита со знаком двоеточия:.С:, D:, E : и т.д.

Изображение слайда

10

Слайд 10

В операционной системе Windows вместо каталогов используется понятие «папка». Папка – это объект Windows, предназначенный для объединения файлов и других папок в группы.

Изображение слайда

11

Слайд 11: Иерархии папок Windows

Изображение слайда

12

Слайд 12

В путь к файлу входят записываемые через разделитель "\" логическое имя диска и последовательность имен вложенных друг в друга папок, в последней из которых находится данный нужный файл. C:\Рефераты\ C:\Рефераты\Физика\Оптические явления. doc C:\Рефераты\Информатика\Интернет. doc C:\Рисунки\ Закат. bmp

Изображение слайда

13

Слайд 13: Полное имя файла

Путь к файлу вместе с именем файла называют полным именем файла. C:\Рефераты\Физика\Оптические явления. doc C:\Рефераты\Информатика\Интернет. doc C:\Рефераты\Информатика\Компьютерные вирусы. doc C:\Рисунки\Закат. jpg C:\Рисунки\ Зима. jpg

Изображение слайда

14

Слайд 14

Решение задач

Изображение слайда

15

Слайд 15

Задача 1 В некотором каталоге хранился файл  Хризантема.doc, имевший полное имя D:\2013\Осень\Хризантема.doc. В этом каталоге создали подкаталог  Ноябрь  и файл Хризантема.doc  переместили в созданный подкаталог. Укажите полное имя этого файла после перемещения. Варианты ответов: 1) D:\2013\Осень\Ноябрь\Хризантема.doc 2) D:\Ноябрь\Хризантема.doc 3) D:\2013\Осень\Хризантема.doc 4) D:\2013\Ноябрь\Хризантема.doc

Изображение слайда

16

Слайд 16

Задача 1 Пояснение: В данном случае, нам известно, что файл лежал в папке Осень: D:\2013\Осень\Хризантема.doc, в папку Осень добавили подпапку Ноябрь, значит в полный путь к файлу добавился Ноябрь. Вывод, полное имя файла стало таким: D:\2013\Осень\Ноябрь\Хризантема.doc Ответ: 1

Изображение слайда

17

Слайд 17

Задача 2 В некотором каталоге хранился файл  Лист.jpg. Затем этот в этом каталоге создали подкаталог и переместили в него файл  Лист.jpg. После этого полное имя файла стало  D:\2016\Осень\Лист.jpg. Укажите полное имя этого файла до перемещения. Варианты ответов: D:\2016\Осень\Ноябрь\Лист.jpg 2) D:\Лист.jpg 3) 2016 4) D:\2016\Лист.jpg

Изображение слайда

18

Слайд 18

Пояснение: Полное имя файла после перемещения: D:\2016\Осень\Лист.jpg Ответ: 4 Задача 2 Удалим из построенного дерева последний подкаталог Осень. Запишем полученное имя файла: D:\2016\Лист.jpg

Изображение слайда

19

Слайд 19

Задача 3 Пользователь работал с каталогом C:\Документы\Договоры\Продажа. Сначала он поднялся на один уровень вверх, затем спустился в каталог  Срочные, затем спустился в каталог  Покупка. Укажите полный путь каталога, в котором оказался пользователь. Варианты ответов: C:\Документы\Срочные \Покупка\Продажа C:\Документы\Договоры\Срочные\Покупка C:\Срочные\Покупка C:\Документы\Срочные\Покупка

Изображение слайда

20

Слайд 20

Пояснение: Ответ: 2 Задача 3 Пользователь работал с каталогом C:\Документы\Договоры\Продажа. Сначала он поднялся на один уровень вверх и оказался в каталоге Договоры. Затем спустился в каталог  Срочные и оказался в каталоге: C:\Документы\Договоры\Срочные. Затем спустился в каталог  Покупка и оказался в каталоге : C:\Документы\Договоры\Срочные\Покупка.

Изображение слайда

21

Слайд 21

Задача 4 В некотором каталоге хранится файл  Компот.doc. После того, как в этом каталоге создали подкаталог и переместили туда файл  Компот.doc, его полное имя стало С:\Дом\Рецепты\Напитки\Компот.dос. Каково имя созданного каталога? Варианты ответов: Дом Рецепты Напитки С:\Дом\Рецепты

Изображение слайда

22

Слайд 22

Пояснение: Ответ: Напитки Задача 4 В некотором каталоге хранится файл  Компот.doc. После того, как в этом каталоге создали подкаталог и переместили туда файл  Компот.doc, его полное имя стало С:\Дом\Рецепты\Напитки\Компот.dос. Файл  Компот.doc оказалс я расположенным в каталоге Напитки

Изображение слайда

23

Слайд 23

Задача 5 На компьютере в офисе туристической фирмы в каталоге Экскурсии хранился файл Байкал. png. Этот каталог перенесли в каталог Реклама, расположенный в корне диска D. Укажите полное имя этого файла после перемещения. Варианты ответов: 1) D:\Байкал. png. 2) D:\Реклама\Байкал. png 3) D:\Реклама\Экскурсии \ Байкал. png 4) D:\Экскурсии\Реклама \ Байкал. png

Изображение слайда

24

Последний слайд презентации: Задание №4 Файловая система

Пояснение: Ответ: 3 Задача 5 На компьютере в офисе туристической фирмы в каталоге Экскурсии хранился файл Байкал. png. Этот каталог перенесли в каталог Реклама, расположенный в корне диска D. Каталог Экскурсии перенесли в каталог Реклама, а каталог реклама расположен в корне диска D. Значит верный ответ: D:\Реклама\Экскурсии \ Байкал. png

Изображение слайда

Многоуровневая защищенная иерархическая файловая система. Коробки представляют ...

Возможность аудита информационных систем играет важную роль в государственном управлении. Доступ информационной системы к ресурсам сохраняется в файлах журнала, чтобы аудиторы могли позже их проверить. Однако есть две проблемы с управлением обычными журналами аудита: i) журналы аудита уязвимы для атак, когда злоумышленники могут подделать данные, не будучи обнаруженными, и ii) могут быть разные заинтересованные стороны с разными ролями и разными уровнями доверия с разными правами доступа к данные.Этот сценарий происходит в судебной системе Португалии, где заинтересованные стороны используют информационную систему, управляемую третьей стороной. В этом документе предлагается использовать технологию блокчейн, чтобы сделать хранение журналов доступа более устойчивым, поддерживая такой сценарий с участием многих заинтересованных сторон, в котором разные объекты имеют разные права доступа к данным. С этой целью мы реализовали это предложение в судебной системе Португалии через JusticeChain. JusticeChain делится на компоненты блокчейна и клиентские компоненты блокчейна.Компоненты блокчейна, реализованные с помощью Hyperledger Fabric, обеспечивают целостность журнала и повышают его отказоустойчивость. Клиентский компонент блокчейна, JusticeChain Client, отвечает за сохранение журналов от имени информационной системы и включает диспетчер журналов JusticeChain и диспетчер аудита JusticeChain. Последний позволяет проводить аудит через блокчейн. Результаты оценки показывают, что система может обеспечить пропускную способность 37 транзакций в секунду и задержку менее 1 минуты. Требуемое хранилище для каждого однорангового узла в течение года составляет порядка терабайт.В качестве расширения JusticeChain, которое обеспечивает еще большее распределение доверия, мы представляем систему контроля доступа на основе блокчейна, JusticeChain v2. JusticeChain v2 позволяет распределить процесс авторизации, обеспечивая при этом те же преимущества, что и JusticeChain. Наша оценка показывает, что наша система может обрабатывать около 250 запросов управления доступом в секунду с задержкой менее 12 секунд. Требуемое хранилище примерно такое же, как у JusticeChain.

Структуры каталогов в операционной системе

Каталог - это контейнер, который используется для хранения папок и файлов.Он упорядочивает файлы и папки в иерархическом порядке.

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

  • Одноуровневый каталог -
    Одноуровневый каталог - это простейшая структура каталогов. В нем все файлы содержатся в одном каталоге, что упрощает поддержку и понимание.

    Одноуровневый каталог имеет существенное ограничение, однако, когда количество файлов увеличивается или когда в системе более одного пользователя.Поскольку все файлы находятся в одном каталоге, они должны иметь уникальное имя. если два пользователя вызывают тест своего набора данных, то правило уникального имени нарушается.

Преимущества:



  • Поскольку это единый каталог, его реализация очень проста.
  • Если файлы меньше по размеру, поиск ускорится.
  • Такие операции, как создание файлов, поиск, удаление, обновление, очень просты в такой структуре каталогов.

Недостатки:

  • Может возникнуть конфликт имен, поскольку два файла не могут иметь одинаковое имя.
  • Поиск займет много времени, если каталог большой.
  • Это не может сгруппировать файлы одного типа вместе.
  • Двухуровневый каталог -
    Как мы видели, одноуровневый каталог часто приводит к путанице в именах файлов у разных пользователей. решение этой проблемы - создать отдельный каталог для каждого пользователя.

    В двухуровневой структуре каталогов у каждого пользователя есть собственный каталог пользовательских файлов (UFD) . UFD имеют схожую структуру, но в каждом перечислены файлы только одного пользователя. Системный каталог главного файла (MFD) выполняет поиск всякий раз, когда новый идентификатор пользователя входит в систему. MFD индексируется по имени пользователя или номеру учетной записи, и каждая запись указывает на UFD для этого пользователя.

Преимущества:

  • Мы можем указать полный путь, например / Имя-пользователя / имя-каталога /.
  • У разных пользователей может быть один и тот же каталог и имя файла.
  • Поиск файлов становится проще благодаря имени пути и группировке пользователей.

Недостатки:

  • Пользователь не может делиться файлами с другими пользователями.
  • Тем не менее, он не очень масштабируемый, два файла одного типа не могут быть сгруппированы одним пользователем.
  • Древовидный каталог -
    После того, как мы увидели двухуровневый каталог как дерево высотой 2, естественным обобщением будет расширение структуры каталогов до дерева произвольной высоты.
    Это обобщение позволяет пользователю создавать свои собственные подкаталоги и соответствующим образом организовывать свои файлы.

Древовидная структура является наиболее распространенной структурой каталогов. У дерева есть корневой каталог, и каждый файл в системе имеет уникальный путь.

Преимущества:

  • Очень общие, поскольку можно указать полное имя пути.
  • Очень масштабируемый, вероятность коллизии имен меньше.
  • Поиск становится очень простым, мы можем использовать как абсолютные, так и относительные пути.

Недостатки:



  • Каждый файл не вписывается в иерархическую модель, файлы могут быть сохранены в нескольких каталогах.
  • Мы не можем делиться файлами.
  • Это неэффективно, потому что доступ к файлу может происходить из нескольких каталогов.
  • Каталог ациклического графа -
    Ациклический граф - это граф без цикла, который позволяет нам совместно использовать подкаталоги и файлы. Один и тот же файл или подкаталоги могут находиться в двух разных каталогах.Это естественное обобщение древовидной структуры каталога.

    Используется в ситуации, когда два программиста работают над совместным проектом и им нужен доступ к файлам. Связанные файлы хранятся в подкаталоге, отделяя их от других проектов и файлов других программистов, поскольку они работают над совместным проектом, поэтому они хотят, чтобы подкаталоги находились в их собственных каталогах. Общие подкаталоги должны быть общими. Итак, здесь мы используем ациклические каталоги.

    Следует отметить, что общий файл не совпадает с файлом копии.Если какой-либо программист внесет какие-либо изменения в подкаталог, это отразится в обоих подкаталогах.

Преимущества:

  • Мы можем делиться файлами.
  • Искать легко благодаря разным-разным путям.

Недостатки:

  • Мы предоставляем общий доступ к файлам посредством ссылки, в случае удаления может возникнуть проблема,
  • Если ссылка является мягкой ссылкой, то после удаления оставленного нами файла с висящим указателем.
  • В случае жесткой ссылки, чтобы удалить файл, мы должны удалить все связанные с ним ссылки.
  • Общая структура каталогов графа -
    В общей структуре каталогов графа в структуре каталогов разрешены циклы, в которых несколько каталогов могут быть получены из более чем одного родительского каталога.
    Основная проблема с такой структурой каталогов заключается в вычислении общего размера или пространства, занятого файлами и каталогами.

Преимущества:

  • Допускает циклы.
  • Более гибкая, чем другие структуры каталогов.

Недостатки:

  • Дороже других.
  • Требуется сборка мусора.

Вниманию читателя! Не прекращайте учиться сейчас. Практикуйте экзамен GATE задолго до самого экзамена с помощью предметных и общих викторин, доступных в курсе GATE Test Series .

Изучите все концепции GATE CS с бесплатными живыми классами на нашем канале YouTube.

Файловая система общего назначения для вторичного хранилища

Р. К. Дейли
Массачусетский технологический институт
Кембридж, Массачусетс
и
П. Г. Нойман
Bell Telephone Laboratories, Inc.
Мюррей-Хилл, Нью-Джерси

1. Введение

Потребность в универсальном интерактивном вторичном запоминающем комплексе в многопрограммной среде огромна.Во время интерактивного взаимодействия приобретаемые пользователем автономные съемные носители информации, такие как карты и ленты, становятся крайне нежелательными. С другой стороны, если все пользователи должны иметь возможность хранить столько информации, сколько они хотят, во вторичном хранилище, доступном для машины, различные потребности становятся критически важными: малоиспользуемая информация должна поступать на устройства с более длительным временем доступа, чтобы оставить достаточно места на более быстрые устройства для более часто используемых файлов. Кроме того, информация должна быть легкодоступной, когда это необходимо, она должна быть защищена от несчастных случаев и злонамеренных действий и при желании должна быть доступна другим пользователям на легко управляемой основе.Наконец, любое соображение, которое не является основным для способности пользователя манипулировать этой информацией, должно быть для него невидимым, если он не укажет иное.

Здесь представлена ​​базовая формулировка файловой системы, разработанной для удовлетворения этих потребностей. Эта формулировка предоставляет пользователю простые средства адресации по существу бесконечного количества вторичной памяти машинно-независимым и аппаратно-независимым образом. Базовая структура файловой системы не зависит от характеристик машины.В иерархии файлов пользователю известны только символьные адреса. Вся физическая адресация многоуровневого комплекса вторичных запоминающих устройств осуществляется файловой системой и не видна пользователю.

В разделе 2 статьи представлена ​​иерархическая структура файлов, которая позволяет гибко использовать систему. Эта структура обладает достаточными возможностями для обеспечения универсальности. Представлен набор репрезентативных функций управления. Также указаны типичные команды файловой системы, но они не подробно описаны; хотя существование этих команд имеет решающее значение, фактические детали их конкретных реализаций могут варьироваться, не влияя на дизайн базовой файловой структуры и управления доступом.

В разделе 3 обсуждается система резервного копирования файлов, благодаря которой вторичное хранилище представляется пользователю как единый по существу бесконечный носитель. Система резервного копирования также предусматривает процедуры аварийной перезагрузки и аварийной перезагрузки в случае отказа машины или системы. Наконец, в разделе 4 дается краткое описание программных модулей файловой системы и их взаимосвязи друг с другом. Модульность конструкции позволяет изменять модули, влияющие на использование вторичного запоминающего устройства, без изменения других модулей.Точно так же файлы не форматируются на уровне файловой системы, поэтому любые изменения формата не влияют на основную структуру файловой системы. Независимость от машины предпринимается везде, где это имеет смысл.

Разделы 2 и 3 по существу автономны, и их можно читать независимо от сопутствующих статей (см. Ссылки 1-5). Раздел 4 требует знания первых трех работ.

2. Файловая структура и контроль доступа

В этом разделе статьи представлена ​​логическая организация файловой структуры.Файловая структура состоит из базовой древовидной иерархии файлов, между которыми могут быть добавлены ссылки для облегчения простого доступа к файлам в других местах иерархии. Каждый файл имеет независимые средства управления способом его использования.

Если файлы должны совместно использоваться различными пользователями таким образом, чтобы можно было гибко управлять ими, желательны различные формы защиты. К ним относятся:

С1 . Безопасность от кого-то маскирующегося под кого-то другого;

С2 .Безопасность от несчастных случаев или злонамеренных действий со стороны кого-либо, кому специально разрешен контролируемый доступ;

S3 . Безопасность от несчастных случаев или злонамеренных действий со стороны кого-то, кому специально отказано в доступе;

S4 . Безопасность от самовольных несчастных случаев;

S5 . Полная конфиденциальность, при необходимости, с доступом только для одного пользователя или группы пользователей;

S6 . Безопасность от сбоев оборудования или системного программного обеспечения;

S7 .Безопасность системы защищает себя от несанкционированного доступа неавторизованных пользователей;

S8 . Защита от чрезмерного применения других мер предосторожности.

Эти гарантии повторятся в последующем обсуждении. Различные функции файловой системы, представленные ниже, кратко описаны в Разделе 2.4, а также то, как эти функции помогают обеспечить вышеуказанные меры безопасности.

2.1 Основные понятия

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

Файл - это просто упорядоченная последовательность из элементов , где элементом может быть машинное слово, символ или бит, в зависимости от реализации.Пользователь может создавать, изменять или удалять файлы только с помощью файловой системы. На уровне файловой системы файл не имеет формата. Все форматирование выполняется модулями более высокого уровня или пользовательскими программами, если это необходимо. Что касается конкретного пользователя, файл имеет одно имя, и это имя является символическим. (Символические имена могут быть произвольно длинными и могут иметь собственный синтаксис. Например, они могут состоять из нескольких частей, некоторые из которых имеют отношение к природе файла, например, ALPHA FAP DEBUG.) Пользователь может ссылаться на элемент в файле, указав символическое имя файла и линейный индекс элемента в файле. Используя модули более высокого уровня, пользователь может также иметь возможность ссылаться на соответствующим образом определенные последовательности элементов непосредственно по контексту.

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

Каждая ветвь содержит описание того, как ее можно использовать и как она используется. Это описание включает такую ​​информацию, как фактический физический адрес файла, время создания или последнего изменения этого файла, время последнего обращения к файлу и информацию об управлении доступом для ветви (см. Ниже).Описание также включает текущее состояние файла (открыт для чтения N пользователями, открыт для чтения и записи одним пользователем, открыт для совместного использования данных N пользователями или неактивен), что обсуждается в разделе 4. Некоторая информация недоступна. пользователю.

Единственная информация, связанная со ссылкой, - это указатель на запись, на которую она ссылается. Этот указатель указывается в виде символического имени, которое однозначно идентифицирует связанную запись в иерархии. Ссылка получает информацию об управлении доступом из ветви, на которую она фактически указывает.

2.2 Иерархия файловой структуры

Здесь обсуждается иерархическая файловая структура. Обсуждение функций управления доступом для выбранной конфиденциальности и контролируемого совместного использования отложено до Раздела 2.3. Для простоты понимания файловую структуру можно представить как дерево файлов, некоторые из которых являются каталогами. То есть, за одним исключением, каждый файл (например, каждый каталог) обнаруживает, что на него прямо указывает ровно одна ветвь ровно в одном каталоге. Исключением является корневой каталог или корень в корне дерева.Хотя на корень явно не указывается из какого-либо каталога, на корень неявно указывает фиктивная ветвь, известная файловой системе.

Файл, на который прямо указывается в каком-либо каталоге, является непосредственно ниже по сравнению с этим каталогом (и каталог непосредственно выше файла). Файл, который непосредственно уступает каталогу, который сам по себе непосредственно уступает второму каталогу , уступает второму каталогу (и аналогично второй каталог на выше файла).Корень имеет нулевой уровень, а файлы, находящиеся непосредственно ниже него, имеют первый уровень. В более широком смысле неполноценность (или превосходство) определяется для любого количества уровней разделения через цепочку непосредственно подчиненных (вышестоящих) файлов. (Читатель, которого беспокоит количество уровней, увеличивающееся с неполноценностью, может притвориться, что номера уровней имеют отрицательные знаки.) В этом случае считается, что ссылки наложены на древовидную структуру, но не зависят от нее. Обратите внимание, что понятия неполноценности и превосходства касаются не ссылок, а только ветвей.

В древовидной иерархии такого рода кажется желательным, чтобы пользователь мог работать в одном или нескольких каталогах, вместо того, чтобы постоянно перемещаться. Таким образом, естественно, что иерархия организована таким образом, чтобы пользователи со схожими интересами могли совместно использовать общие файлы и при желании иметь личные файлы. В любой момент времени считается, что пользователь работает в каком-то одном каталоге, который называется его рабочий каталог . Он может получить доступ к файлу, на который фактически указывает запись в его рабочем каталоге, просто указав имя записи.Один и тот же рабочий каталог одновременно может иметь несколько пользователей.

Рисунок 1. Пример иерархии без ссылок.

Пример простой древовидной иерархии без ссылок показан на рис. 1. Нетерминальные узлы, которые показаны в виде кружков, указывают файлы, которые являются каталогами, в то время как линии вниз от каждого такого узла указывают записи (т. Е. Ветви) в каталоге. соответствующий этому узлу. Терминальные узлы, показанные в виде квадратов, обозначают файлы, отличные от каталогов.Буквы обозначают имена записей, а числа используются только в описательных целях, чтобы идентифицировать каталоги на рисунке. Например, буква «J» - это имя записи для различных записей в разных каталогах на рисунке, а цифра «0» относится к корню.

Имя записи имеет смысл только по отношению к каталогу, в котором оно встречается, и может быть или не быть уникальным за пределами этого каталога. По разным причинам желательно иметь символическое имя, которое однозначно определяет запись в иерархии в целом.Такое имя получается относительно корня и называется именем дерева . Он состоит из цепочки имен записей, необходимых для доступа к записи через цепочку ответвлений от корня. Например, имя дерева каталога, соответствующего узлу, отмеченному 1 на рис. 1, - A: B: C, где двоеточие используется для разделения имен записей. (Два файла с именами записей D и E, показанные в этом каталоге, имеют имена деревьев A: B: C: D и A: B: C: E, соответственно.) В большинстве случаев пользователю не нужно знать имя дерева записи.

Если специально не указано иное, имя дерева файла определяется относительно корня. Однако файл также может иметь однозначное имя относительно произвольного каталога, как показано ниже. Если файл X уступает каталогу Y. имя дерева X относительно Y - это цепочка имён записей, необходимых для достижения X из Y. Если X превосходит Y. имя дерева X относительно Y состоит из цепочка звездочек, по одной для каждого уровня непосредственного превосходства. (Обратите внимание, что, поскольку рассматривается только древовидная структура, каждый файл, кроме корневого, имеет ровно один непосредственно вышестоящий файл.) Если файл не ниже и не превосходит каталог, сначала найдите каталог Z с максимальным уровнем, который превосходит как X, так и Y. Затем имя дерева X относительно Y состоит из имени дерева Z относительно X (цепочка звездочек), за которой следует имя дерева Y относительно Z (цепочка имен входов). В качестве примера на рис. 1 рассмотрим два каталога, отмеченные 1 и 2. Имя дерева 1 относительно 2: *: B: C, а имя дерева 2 относительно 1: *: *: F. Начальное двоеточие используется для обозначения имени, относящегося к рабочему каталогу.

Ссылка с произвольным именем (LINKNAME) может быть установлена ​​на запись в другом каталоге с помощью команды

LINK LINKNAME, PATHNAME.

(Команда - это просто вызов подпрограммы.) Имя записи, которая должна быть связана с (PATHNAME), может быть указано как имя дерева относительно рабочего каталога или корня, или, в более общем смысле, как имя пути (определенное ниже) . Обратите внимание, что файл может иметь разные имена для разных пользователей в зависимости от того, как к нему обращаются.Ссылка служит ярлыком для ветки где-то еще в иерархии и дает пользователю иллюзию, что ссылка на самом деле является ветвью, указывающей непосредственно на желаемый файл. Хотя ссылки не добавляют базовых возможностей к тем, которые уже присутствуют в древовидной структуре ветвей, они значительно облегчают использование файловой системы. Ссылки также помогают избавиться от необходимости дублировать копии файлов для совместного использования. Наложение ссылок на древовидную структуру рис. 1 показано на рис.2. Пунктирные линии вниз от узла показывают записи, которые являются ссылками на другие записи. Когда ссылки добавляются в древовидную структуру, результатом является ориентированный граф. (Направление, конечно, вниз от каждого узла.)

Рис. 2. Пример Рис. 1 с добавленными ссылками.

В примере на рис. 2 запись с именем G в каталоге 2 является ссылкой на ветвь с именем C в каталоге 3. Запись с именем C в каталоге 4 (напомним, что имена записей не обязательно должны быть уникальными, кроме как внутри каталога) является ссылка на запись G в каталоге 2 и, таким образом, действует как ссылка на C в каталоге 3.Обе эти ссылки фактически указывают на каталог 1.

Желательно иметь имя, аналогичное имени дерева, которое включает ссылки. Таким именем является имя пути , и предполагается, что оно относится к корню, если специально не указано иное. Имя пути к файлу (относительно корня) - это цепочка имен записей, используемых для имени файла, относительно корня. (Например, каталог 1 на рис. 2 может иметь имя пути A: B: C; D, A: F: G или H: C, в зависимости от его использования.) Рабочий каталог всегда определяется в виде имени пути. Пользователь может изменить свой рабочий каталог с помощью такой команды, как

ИЗМЕНЕННОЕ ИМЯ ПУТИ,

где имя пути может относиться к (старому) рабочему каталогу или корню. Определение имени пути относительно каталога, отличного от корня, аналогично определению имени дерева, за следующими исключениями: концепция файла, непосредственно подчиненного каталогу, заменяется концепцией файла, на который фактически указывает по записи.Концепция каталога, непосредственно превосходящего файл, заменяется концепцией, которая хорошо определяется только как инверсия указанного выше эффективного указателя, то есть зависит от того, какая запись в каком каталоге ранее использовалась для доступа к файлу.

В общем, любой файл может быть указан с помощью имени пути (которое на самом деле может быть именем дерева или именем записи) относительно текущего рабочего каталога. Файл также может быть указан с помощью имени пути относительно корня. В первом случае имя пути начинается с двоеточия, во втором - нет.

Чтобы проиллюстрировать эти несколько неуловимые концепции, рассмотрим пример на рис. 2. Предположим, что рабочий каталог имеет имя пути H (т. Е. Каталог 4). Команда

ИЗМЕНЕННАЯ КАТЕГОРИЯ: C

приводит к рабочему каталогу с именем пути H: C (т. е. каталог 1). Последующая ссылка на файл с именем пути: *: 1 (относительно рабочего каталога с именем пути H: C) относится к файлу 5 на рисунке. Команда

ИЗМЕНЕННАЯ КАТЕГОРИЯ: *

приводит к восстановлению исходного рабочего каталога с именем пути H.(При такой интерпретации * пользователь считает, что он работает в дереве. Обратите внимание, что дизайн может быть изменен так, чтобы путь, отличный от того, который использовался на пути вниз, мог использоваться на обратном пути к корню, но не без значительного усложнения конструкции.)

Патологический случай, упомянутый выше в отношении ссылки, фактически указывающей на файл, возникает следующим образом. Рассмотрим снова рис. 2. Предположим, что ветвь C в каталоге 3 удалена из этого каталога; Предположим также, что в том же каталоге затем устанавливается ссылка с именем C на запись C в каталоге 4, e.г., с помощью команды

ССЫЛКА C, H: C.

Доступ к записи C в каталоге 3 (или к записи G в 2 или C в 4, если на то пошло) приводит к возникновению цикла, в котором никогда не было найдено ни одной ветви. Этот и аналогичные циклы, в которых не найдено ни одной ветви, могут быть разорваны различными способами, например, путем наблюдения за тем, используется ли запись дважды при одном и том же доступе. Обратите внимание, что могут возникнуть гораздо более хитрые петли, например, возникающие в результате установления связи (с именем K) от каталога 1 до записи H в корне.Тогда имя пути: C: K относительно каталога 4 относится к самому каталогу 4. Этот и аналогичные циклы, которые включают цепочки каталогов, являются неотъемлемой частью использования ссылок и фактически могут использоваться конструктивно.

2.3 Контроль доступа

Обычно желательна процедура первоначального входа в систему, чтобы установить личность пользователя для целей бухгалтерского учета. Также может потребоваться контролировать способ использования системы пользователем. Существует два основных подхода к использованию описанной здесь иерархии файлов.Во-первых, файловая структура может быть , по существу, открытой , с неограниченным начальным доступом и с последующим доступом, разрешенным для всех других каталогов, если специально не отказано. С другой стороны, файловая структура может быть , по существу, закрытой , с начальным доступом, ограниченным для любого пользователя конкретным начальным каталогом (при условии, что он может указать пароль, например), и с последующим отказом в доступе к другим каталогам, если специально не разрешено. . Фактически, есть аргументы в пользу каждой крайности.Принципиально открытая схема подразумевает, что замки нужно размещать только там, где они необходимы (и наиболее эффективны). По существу закрытая схема обеспечивает четко определенные рабочие области, освобождает пользователя от беспокойства о других пользователях и помогает предотвратить случайное изменение файлов пользователя. Можно заметить, что объем возможностей описанной здесь файловой структуры не зависит от того, является ли структура по существу открытой или закрытой. На практике, вероятно, возникнет позиция где-то посередине между двумя крайностями.

Попытка получить доступ к файлу может или не может быть успешной, в зависимости от того, что он пытается сделать. Теперь рассматривается базовая структура, в которой предоставляются разрешения. Эта структура не зависит от описанной выше файловой структуры. Хотя точный набор разрешений может поэтому варьироваться от системы к системе, здесь в качестве иллюстрации приводится гибкий набор, подходящий для нормального использования. Все разрешения логически находятся в ветвях, которые указывают на файлы. (На практике, однако, в некоторых случаях могут быть разрешения, связанные с каталогом, а не повторяющиеся для каждой записи в этом каталоге.)

Набор разрешений, с которыми данный пользователь может получить доступ к определенной ветви, называется режимом ветви для этого пользователя. С каждой ветвью связан список управления доступом , который содержит список пользователей (или групп пользователей) вместе с соответствующим режимом, связанным с каждым пользователем. Разрешения для любых пользователей в списке могут быть отменены (при условии разрешения на это - см. Ниже) путем добавления в список последующих пользователей и режимов. Список сканируется в порядке давности, поэтому добавление действует как переопределение.(Каждый раз, когда список управления доступом изменяется, выполняется сборка мусора, чтобы список оставался неизбыточным.) Вся информация управления доступом, необходимая для использования данного файла, содержится в списке в ветви, указывающей на этот файл, и таким образом, не зависит от способа доступа к файлу.

Режим состоит из пяти атрибутов с именами TRAP, READ, EXECUTE, WRITE и APPEND, каждый из которых либо включен, либо выключен. При выполнении контроля доступа в первую очередь проверяется атрибут TRAP.Он сам по себе достаточно мощный, чтобы выполнять роли остальных четырех атрибутов, которые называются атрибутами использования . Однако четыре атрибута использования включены сюда для простоты описания, а также для простоты использования системы. Четыре атрибута использования указывают разрешение на выполнение заданного действия в ветке конкретным пользователем, только если соответствующий атрибут включен. Теперь функция каждого атрибута определена.

ЛОВУШКА . Когда в ветви установлен атрибут TRAP для данного пользователя, прерывание происходит при любой ссылке этого пользователя, которая влияет на содержимое файла, на который указывает эта ветвь.В этом случае модуль управления доступом вызывает процедуру, имя которой указано как первая запись в списке прерываний . Список прерываний может быть связан с каждым пользователем в списке управления доступом. Дополнительные параметры могут быть определены в списке прерываний и передаются как константы в вызываемую процедуру. Кроме того, вся соответствующая информация, касающаяся ветвления, а также вызывающей последовательности, которая вызвала прерывание, передается вызываемой процедуре. Прерывания обрабатываются в порядке, указанном в списке прерываний.Возврат к модулю управления доступом определяет действующие значения четырех атрибутов использования, которые должны управлять доступом. Возвращаемое значение может переопределять начальные значения этих атрибутов.

Пользователь ветки может запретить процесс ловушки. В этом случае все ссылки на запись с включенным атрибутом TRAP вызывают возврат к вызывающей процедуре с ошибкой. Атрибут TRAP чрезвычайно полезен для мониторинга использования файлов, для наложения дополнительных ограничений на доступ (например,g., прикладываемые пользователем блокировки) для получения подпрограмм, только если и когда на них действительно есть ссылка, и т. д. Пара команд, таких как LOCK и UNLOCK, предоставляет пользователю стандартный способ наложения блокировок на запись.

ЗАБЛОКИРОВАТЬ ИМЯ ФАЙЛА, КЛЮЧ

РАЗБЛОКИРОВАТЬ ИМЯ ФАЙЛА

(FILENAME - это имя ветки, заданное в качестве имени пути.) Команда LOCK вставляет ловушку, которая при каждой попытке доступа может запрашивать у пользователя назначенный ключ и разрешать доступ только в том случае, если ключ указан правильно.РАЗБЛОКИРОВАТЬ снимает блокировку. (Команда временной блокировки также может быть желательной, например, чтобы сделать данную ветвь доступной для определенного пользователя только между определенным временем в определенные дни.) Эти команды доступны пользователю только в том случае, если ветка указывает на каталог, содержащий запись В FILENAME для этого пользователя установлен атрибут WRITE (см. Ниже).

Атрибуты использования . Атрибуты READ, EXECUTE, WRITE и APPEND управляют разрешением на выполнение операций с файлами с определенными намерениями, с намерением, соответствующим каждому атрибуту.Каждая операция в данной ветви подразумевает одно из четырех намерений, а именно : чтение, выполнение, запись или добавление . Интерпретация намерения зависит от того, указывает ли ветвь, к которой осуществляется доступ, на каталог (ветвь каталога ) или на не директорию (ветка вне директории ), как показано ниже.

Если ветвь не является директорией, смысл каждого намерения довольно прост. Намерение чтения - это желание прочитать содержимое файла. Целью выполнения является желание выполнить содержимое файла как процедуру.Намерение записи - это желание изменить содержимое файла, не добавляя его в конец. Цель добавления - это желание добавить в конец файла без изменения его исходного содержимого. Атрибут в ветке, не относящейся к каталогу, который соответствует конкретному назначению операции в этой ветке, указывает разрешение на выполнение этой операции, только если этот атрибут включен.

Если ветвь является ветвью каталога, значение каждого намерения отличается. Намерение чтения - это желание прочитать то содержимое каталога, которое может быть доступно пользователю, т.е.е., чтобы получить подробную информацию о записях справочника. Целью выполнения является желание выполнить поиск в каталоге. Намерение записи - это желание изменить существующие записи в каталоге без добавления новых. Это включает в себя переименование записей, удаление записей и изменение списка управления доступом для филиалов в этом каталоге. Последний из них включает добавление ловушек в список ловушек и изменение атрибутов использования. Цель добавления - это желание добавить новые записи без изменения исходных записей.Атрибут в ветви каталога, который соответствует конкретному назначению операции в этой ветви, указывает разрешение на выполнение этой операции, только если этот атрибут включен.

Приведено несколько дополнительных примеров системных команд. Предполагая, что необходимые атрибуты WRITE включены для соответствующих ветвей каталога, пользователь может с помощью подходящих команд изменять список управления доступом или удалять записи различными способами. Например, он может изменить (там, где это разрешено атрибутом WRITE подчиненной ветви) список для всех подчиненных ветвей каталога, или для всех подчиненных ветвей, не относящихся к каталогу, или для всех подчиненных ветвей, не относящихся к каталогу, имена которых включают части FAP DEBUG, или для всех Справочник ветвей не более чем на некоторое количество нижних уровней.Точно так же может быть создана сложная команда удаления. (С возможностью того, что ни у кого нет атрибута WRITE для данной ветки каталога, можно бороться различными способами. Один из способов - запретить изменение в списке, которое вызывает это обстоятельство, другой способ - сделать это условие подразумевающим без ограничений.)

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

2.4 Обзор функций файловой системы

На этом этапе желательно суммировать различные функции файловой системы и указать, какие из них вносят вклад в какую из мер защиты от S1 до S8, упомянутых выше. Основные характеристики файловой системы можно сформулировать следующим образом:

F1 . Присущая самой файловой системе иерархическая структура;

F2 . Управление доступом, которое может быть связано с веткой каталога;

F3 .Процедуры резервного копирования (обсуждаются в следующем разделе).

Кроме того, определенные аспекты аппаратного обеспечения и центрального программного обеспечения также способствуют обеспечению этих гарантий:

F4 . Аппаратное обеспечение и центральное программное обеспечение. [2,3]

Способы, которыми меры безопасности S1-S8 взаимодействуют с функциями F1-F4, сведены в Таблицу 1.

  Таблица 1. Особенности файловой системы и какие
  Гарантии, которые они помогают обеспечить.Гарантии MASQ PERM DENY SELF PRIV BUGS TAMP ZEAL
  Особенности S1 S2 S3 S4 S5 S6 S7 S8
  F1. Иерархия Y Y Y Y Y
  F2. Атрибуты Y Y Y Y Y Y Y Y
  F3. Резервное копирование Д Д Д Д
  F4. Система Д Д Д Д

  Примечание: Д = ДА, функция помогает. Пробел = НЕТ, это не так.
 

3. Резервное копирование и извлечение вторичного хранилища

Одним из важных аспектов файловой системы является то, что у пользователя создается иллюзия, что емкость файлового хранилища бесконечна.Эта концепция считается чрезвычайно важной, поскольку она возлагает всю ответственность за запоминание файлов на систему, а не на отдельного пользователя. Многие компьютерные системы уже занимаются предоставлением пользователям магнитных лент и картотек. Предполагается, что большая часть этой потребности будет заменена файловой системой более общим и упорядоченным образом.

Та часть комплекса хранения файловой системы, которая непосредственно доступна файловой системе, т.е.е. диски и барабаны, называется он-лайн системой хранения . Устройства, которые являются съемными из комплекса хранения, такие как ленты, ячейки данных и дисковые пакеты, которые используются файловой системой в качестве расширения онлайновых средств, называются системой хранения резервных копий файлов . Для пользователя все файлы кажутся подключенными, хотя доступ к некоторым файлам может быть несколько отложен. В целях обсуждения рассматривается система резервного копирования, состоящая только из магнитной ленты. Однако представленная здесь система легко адаптируется к другим устройствам.

Инкрементный дамп новых файлов

Каждый раз, когда пользователь выходит из системы, дополнительные копии всех файлов, созданных или измененных этим пользователем, делаются в двух экземплярах на паре магнитных лент. В конце каждого N-часового периода все вновь созданные или измененные файлы, которые ранее не были выгружены, также копируются на эти ленты. Когда это будет сделано, ленты удаляются из машины и заменяются новым набором лент на следующий N-часовой период. Обычно N составляет от 2 до 4 часов.Эта процедура имеет то преимущество, что последствия самого катастрофического отказа машины или системы могут быть ограничены периодом сброса N часов.

Еженедельный дамп часто используемых файлов

В случае катастрофы оперативная система хранения может быть перезагружена с этих дополнительных лент дампа. Однако, поскольку многие ценные файлы, включая системные программы, могли не изменяться в течение года и более, этот метод перезагрузки слишком непрактичен. Чтобы свести к минимуму время, необходимое для восстановления после катастрофы, еженедельно готовится дамп всех файлов, которые использовались в течение последних M недель.Этот дамп также сделан на дублирующих лентах для надежности.

Фактически этот недельный дамп разбит на две части. Первая часть состоит из всех файлов, которые должны присутствовать для запуска и работы базовой системы. Вторая часть состоит из всех остальных файлов, которые использовались за последний период M недель. Обычно период M составляет от трех до пяти недель. Ленты еженедельной свалки могут быть переданы для другого использования примерно через два или три месяца. Ленты инкрементального дампа должны храниться неограниченное время.Однако может быть полезно периодически объединять эти ленты, удаляя устаревшие файлы.

Процедура перезарядки после катастрофы

Если произойдет катастрофа, при которой будет потеряно все содержимое онлайн-системы хранения, можно использовать следующую процедуру перезагрузки. Сначала перезагрузите копию системных файлов с последних еженедельных лент дампа. Когда это будет сделано, система может быть запущена, а остальная часть процесса перезагрузки будет продолжаться под контролем системы.Обратите внимание, что это не обязательно самая последняя копия системы. Если после создания еженедельного дампа в систему было внесено важное изменение, может потребоваться перезагрузить дополнительные ленты перед запуском системы.

После перезагрузки системных файлов ленты инкрементного дампа перезагружаются в обратном хронологическом порядке, начиная с самого последнего набора добавочных лент. Этот процесс продолжается до тех пор, пока не будет достигнуто время последнего еженедельного дампа.В это время перезагружается вторая часть еженедельных лент дампа. Во время этого процесса все избыточные или устаревшие файлы игнорируются. Дата и время создания или последнего изменения файла используются, чтобы гарантировать, что только самая последняя копия файла останется в системе онлайн-хранилища. Поскольку каталоги выгружаются и перезагружаются так же, как и обычные файлы, содержимое онлайн-системы хранения может быть точно восстановлено.

Можно продолжать загружать старые еженедельные ленты, пока он-лайн система не будет полностью перезагружена.Однако количество новой информации, полученной с этих лент, становится все меньше по мере того, как мы возвращаемся в прошлое. В связи с этим файлы, которые не появляются на самом последнем наборе еженедельных лент дампа из-за бездействия, в это время не перезагружаются. Вместо этого в соответствующую ветвь каталога добавляется ловушка, чтобы при первом обращении к файлу вызывалась процедура извлечения. Это позволяет перезагружать эти файлы по мере необходимости с помощью механизма поиска, который обсуждается далее в этом документе.

Процедура спасения при хранении в интерактивном режиме

Хотя процедура аварийной перезагрузки может точно реконструировать содержимое оперативной системы хранения, она обычно используется только как средство защиты от самых катастрофических отказов машины или системы. Когда происходят более легкие и более частые отказы, часто можно спасти содержимое вторичного хранилища, не прибегая к процедуре перезагрузки. Если это можно сделать, можно будет сохранить множество файлов, которые были созданы или изменены после окончания последнего периода инкрементного дампа.Кроме того, можно сэкономить большую часть времени, необходимого для запуска процедуры перезагрузки.

Обычным результатом сбоя машины или системы является то, что содержимое вторичного хранилища остается в состоянии, которое является несовместимым. Например, две совершенно не связанные записи каталога могут в конечном итоге указывать на одно и то же физическое местоположение во вторичной памяти, в то время как таблицы назначения хранилищ указывают, что эта область хранения не используется. Если бы система была перезапущена в это время, ситуация могла бы никогда не разрешиться.Обычный эффект заключается в том, что любая информация, впоследствии назначенная этой области вторичного хранилища, вероятно, будет перезаписана.

Эта ситуация возникает, когда система выходит из строя до того, как файловая система обновит свои таблицы назначения и каталоги на вторичном хранилище. Вероятно, произошло то, что какой-то пользователь удалил файл, а другой пользователь создал новый файл, который был назначен области хранения, только что освобожденной предыдущим файлом. Когда система выходит из строя, изменения не записываются во вторичное хранилище.Это только один пример типа неисправности, которая возникает, когда система неожиданно выходит из строя.

Процедура восстановления предназначена для чтения всех каталогов в иерархии и исправления противоречивой информации там, где это возможно. Остальные ошибочные файлы и записи каталога удаляются или усекаются в точке, в которой была обнаружена ошибка. Таблицы назначения хранилищ исправлены так, что только одна ветвь указывает на одну и ту же область вторичного хранилища. Поскольку необходимо читать только каталоги и таблицы назначения хранилищ, процедура восстановления может выполняться за небольшой процент времени, необходимого для выполнения процедуры полной перезагрузки.

Процедура восстановления также служит полезным инструментом диагностики, поскольку она обеспечивает распечатку каждой обнаруженной ошибки и предпринятых действий. Эту программу также можно запустить в режиме, в котором она только обнаруживает ошибки, но не пытается их исправить.

Извлечение файлов из резервного хранилища

Если файл не был явно удален пользователем, запись каталога для этого файла остается в файловой системе на неопределенный срок. Если по какой-то причине файл, связанный с этой записью, в настоящее время не находится на оперативном запоминающем устройстве, соответствующая ветвь для этого файла содержит ловушку для процедуры извлечения файла.Когда пользователь ссылается на файл, который находится в этом состоянии, его процесс перехватывает процедуру извлечения. В это время пользователь может выбрать дождаться, пока файл будет извлечен из системы резервного копирования, запросить извлечение файла, пока он работает над чем-то еще, прервать процесс, запросивший файлы, или удалить запись в каталоге.

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

Если пользователь удаляет файл, удаляются и файл, и соответствующая запись в каталоге. Однако, если копия этого файла появляется на наборе лент инкрементного дампа, эта копия в настоящее время не удаляется.Этот файл все еще можно получить, если пользователь укажет приблизительную дату и время, когда файл был создан или в последний раз изменен. Чтобы помочь пользователю в этой ситуации, процедура инкрементного дампа предоставляет операционному персоналу список содержимого каждого набора добавочных лент. Эти списки хранятся в журнале регистрации, к которому операторы могут обращаться в ситуациях, подобных описанной выше. Выбранные части этого списка могут быть доступны пользователю.

Пользователь может заявить, что он желает удалить определенный файл из онлайн-системы хранения, не удаляя соответствующую запись в каталоге.Это может быть выполнено с помощью системной процедуры, которая переводит файл в состояние, при котором он может быть извлечен с помощью обычной процедуры извлечения.

Общая надежность

Поскольку файловая система предназначена для обеспечения основного хранилища информации для всех пользователей системы, полная ответственность за все соображения надежности лежит на файловой системе. По этой причине во всех процедурах выгрузки, извлечения и перезагрузки используются повторяющиеся наборы лент. Эти ленты отформатированы таким образом, чтобы свести к минимуму возможность возникновения неисправимых ошибок.При чтении с этих лент во время процесса перезагрузки или извлечения можно исправить несколько ошибок на обоих наборах лент, если ошибки не возникают в одной и той же физической записи обеих лент. Если возникает ошибка, которую невозможно исправить, теряется только ошибочная информация. Если ошибка является простой ошибкой четности, информация принимается, как если бы ошибки не было. Когда пользователь впервые пытается использовать файл, в котором обнаружена ошибка четности или другая ошибка, он уведомляется об этом условии через системную процедуру, использующую механизм ловушки.

Выделения вторичного хранения

Файловая система по мере необходимости динамически назначает все вторичные хранилища. Как правило, никакие области онлайн-системы хранения не закреплены за пользователем. Пользователь может хранить в файловой системе практически бесконечное количество информации. Однако необходимо контролировать количество информации, которая может храниться в онлайн-системе хранения одновременно.

Когда пользователь впервые входит в систему, файловой системе присваивается имя или номер учетной записи.Все файлы, впоследствии созданные этим пользователем, помечаются его именем учетной записи. Когда пользователь желает увеличить использование вторичного хранилища, файловая система вызывает процедуру учета вторичного хранилища, сообщая имя учетной записи пользователя, а также объем и класс запрошенного хранилища.

Процедура бухгалтерского учета ведет учет всего использования вторичных хранилищ и их выделений. Выделение хранилища определяется как количество информации, которую конкретная учетная запись может хранить в системе онлайн-хранилища одновременно.Обычно процедура учета позволяет процессу превысить выделенное после сообщения файловой системе о превышении лимита на счету. Однако процедура учета может решить прервать процесс пользователя, если объем уже используемого онлайн-хранилища кажется необоснованным.

Многоуровневый характер вторичного хранилища

В большинстве случаев пользователю не нужно знать, как и где файл хранится в файловой системе. Основная забота пользователя заключается в том, чтобы файл был ему доступен, когда он ему понадобится.Как правило, только файловая система знает, на каком устройстве находится файл.

Файловая система разработана с учетом любой конфигурации вторичных запоминающих устройств. Эти устройства могут охватывать широкий диапазон скоростей и мощностей. Все соображения относительно скорости и эффективности устройств хранения оставлены на усмотрение файловой системы. Таким образом, все пользовательские программы и все другие системные программы не зависят от конкретной конфигурации вторичного хранилища.

Всем постоянным вторичным запоминающим устройствам присваивается номер уровня в соответствии с относительной скоростью устройства.Устройствам с наивысшими скоростями передачи и доступа присваиваются номера наивысшего уровня. Когда файлы становятся активными, они автоматически перемещаются на доступное запоминающее устройство самого высокого уровня. Этот процесс ограничен такими соображениями, как размер файла и частота использования.

Поскольку на определенном устройстве хранения требуется больше места, наименее активные файлы перемещаются на устройство хранения более низкого уровня. В первую очередь перемещаются файлы, принадлежащие аккаунтам с избыточным балансом.Файлы продолжают перемещаться в хранилище более низкого уровня до тех пор, пока не будет освобожден желаемый объем хранилища более высокого уровня. Если файл необходимо переместить с самого нижнего уровня интерактивного запоминающего устройства, файл удаляется, а ветвь для этого файла устанавливается на перехват процедуры извлечения.

4. Структура программы файловой системы

В этом разделе описывается основная программная структура файловой системы, представленная в предыдущих разделах, реализованная в системе Multics. [1] (Здесь предполагается, что читатель знаком с статьями, указанными в ссылках 1, 2 и 3.)

Пользователь может ссылаться на элементы данных в файле явно с помощью операторов чтения и записи или неявно с помощью адресации сегментов. Здесь следует отметить, что слово «файл» не используется в традиционном смысле (т.е. для обозначения какого-либо устройства ввода или вывода). В системе Multics файл представляет собой линейный массив данных, на который ссылаются посредством символьного имени или номера сегмента и линейного индекса. Как правило, пользователь не знает, как и на каком устройстве хранится файл.

Файл Multics - это сегмент, а все сегменты - это файлы. [1,3] Хотя на файл иногда можно ссылаться как на устройство ввода или вывода, через адресацию сегмента можно ссылаться только на файл. Например, лента или телетайп не могут рассматриваться как сегмент и, следовательно, не могут рассматриваться как файл в соответствии с этим определением.

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

4.1 Базовая файловая система

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

который управляет сегментами. В целом этот пакет выполняет следующие основные функции.

  1. Ведение каталогов существующих сегментов (файлов)
  2. Сделать сегменты доступными для процесса по запросу.
  3. Создать новые сегменты.
  4. Удалить существующие сегменты.

Рисунок 3. Базовая файловая система.

На рисунке 3 представлена ​​грубая блок-схема модулей, составляющих базовую файловую систему. Эта диаграмма ни в коем случае не является полной, но используется здесь, чтобы дать читателю общее представление об основном потоке. Направляющие линии указывают поток управления посредством использования формальных последовательностей вызовов с подразумеваемым формальным возвратом. Линии с двойными стрелками используются для обозначения возможного потока управления в любом направлении.Кружками на схеме обозначены некоторые базы данных, общие для указанных модулей. Модули и базы данных, нарисованные под пунктирной линией, должны, по крайней мере, частично постоянно находиться в основной памяти, поскольку они будут вызываться во время ошибки отсутствия страницы (см. Ссылку 3).

Модуль управления сегментами

Модуль управления сегментами ведет записи всех сегментов, которые известны текущему процессу. Сегмент известен процессу после того, как номер сегмента был назначен этому сегменту для этого процесса.Сегмент, который известен процессу, - это активных , если таблица страниц для этого сегмента в настоящее время находится в ядре. Если таблица страниц в настоящее время не находится в ядре, этот сегмент неактивен.

Если сегмент известен процессу, запись для этого сегмента будет существовать в таблице имен сегментов (SNT). Эта запись содержит имя вызова, имя дерева и номер сегмента сегмента (файла), а также другую информацию, относящуюся к сегменту, используемому этим процессом.Имя вызова - это символическое имя, используемое пользователем для ссылки на сегмент. Это имя обычно соответствует записи в иерархии каталогов пользователя, которая фактически указывает на желаемый файл. Следует отметить, что для каждого отдельного процесса существует отдельная копия таблицы имен сегментов.

Если сегмент активен, запись для этого сегмента существует в таблице состояния сегмента (SST). Эта таблица является общей для всех процессов и содержит запись для каждого активного сегмента.Если сегмент неактивен (в ядре нет таблицы страниц), для этого сегмента в этой таблице нет записи. Каждая запись в таблице состояния сегмента содержит такую ​​информацию, как количество процессов, которым известен этот сегмент, и указатель, который может использоваться для ссылки на файл или файлы, которые должны принимать все операции ввода-вывода, возникающие в результате разбиения на страницы этого сегмента. ядра. [3] Когда пользователь впервые обращается к сегменту, возникает направленная ошибка. В это время управление передается процедуре, известной как компоновщик. [3] Эта процедура берет символическое имя вызова сегмента из указателя, содержащегося в машинном слове, вызвавшем ошибку. Теперь компоновщик должен установить номер сегмента из этого символического имени. Именно для этого предусмотрен вход в модуль управления сегментами. Когда к модулю управления сегментами делается вызов, чтобы установить номер сегмента из имени вызова, в таблице имен сегментов выполняется поиск этого имени вызова. Если имя вызова находится в таблице имен сегментов, номер сегмента из этой таблицы немедленно возвращается вызывающей процедуре.Однако, если это не так, модуль управления сегментами должен предпринять следующие шаги.

  1. Найдите сегмент (файл) в иерархии каталогов пользователя с помощью вызова модуля поиска.
  2. Назначьте номер сегмента для этого сегмента.
  3. Обновите таблицу имен сегментов, указав, что этот сегмент теперь известен этому процессу.
  4. Откройте файл или файлы, которые должны получать ввод-вывод в результате разбиения на страницы.
  5. Создайте или обновите соответствующую запись в таблице статуса сегмента.
  6. Установите таблицу страниц и дескриптор сегмента для этого сегмента, если сегмент еще не был активен для какого-либо другого процесса.
  7. Вернуть номер сегмента в вызывающую процедуру.

Если сегмент известен процессу, но в настоящее время не активен, дескриптор для этого сегмента укажет на состояние ошибки. Если и когда возникает эта ошибка, сегмент можно повторно активировать, найдя одобренную частную запись в таблице имен сегментов и повторив шаги с 4 по 7.Обратите внимание, что сегмент не должен быть снова расположен в иерархии каталогов, поскольку имя дерева сохраняется в таблице имен сегментов.

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

Если сегмент должен быть скопирован, на самом деле задействованы два открытых файла: исходный файл и копия или исполняемый файл . Когда таблица страниц изначально создается модулем управления сегментами, каждая запись в этой таблице страниц будет содержать указание на ошибку и флаг, указывающий, какое действие следует предпринять, если и когда возникнет эта ошибка. Этот флаг может указывать на одно из следующих действий:

  1. Назначьте пустую страницу.
  2. Извлечь недостающую страницу из исходного файла.
  3. Получить недостающую страницу из исполняемого файла.

После того, как страница была выгружена (записана) в исполняемый файл, она должна быть извлечена из этого файла.

Предоставляется запись в модуль управления сегментом, с помощью которой пользователь может объявить синоним или список синонимов для имени сегмента. Например, у пользователя может быть определенная процедура, которая ссылается на сегмент под названием «Гамма», и другая процедура, которая ссылается на сегмент под названием «Альфа».«Если пользователь желает использовать обе процедуры как часть одного и того же процесса, используя сегмент под названием« Данные », он может сделать это, объявив альфа и гамма синонимами данных. Эта связь сохраняется модулем управления сегментами в таблице синонимов. (SYNT). Каждый раз, когда модуль управления сегментом представлен с именем вызова, которое было определено как синоним, соответствующее имя заменяется перед любой дальнейшей обработкой.

В дополнение к функциям, описанным выше, модуль управления сегментами предоставляет записи, с помощью которых пользователь может задавать вопросы или делать объявления, связанные с использованием сегментов, известных его процессу.Некоторые из этих функций перечислены ниже.

  1. Объявить, что сегмент или некоторые определенные местоположения в сегменте больше не нужны в настоящее время.
  2. Объявить, что сегмент или некоторые определенные местоположения в сегменте должны быть переназначены, а не загружены по мере необходимости. (Пользователь собирается перезаписать эти места.)
  3. Спросите, находятся ли в настоящее время сегмент или некоторые определенные местоположения внутри сегмента в ядре.
  4. Объявить, что определенный сегмент должен быть создан при первой ссылке.
  5. Завершить сегмент, показывая, что этот сегмент больше не считается известным этому процессу.

Модуль поиска

Модуль поиска вызывается модулем управления сегментами для поиска определенного сегмента (файла) в иерархии каталогов пользователя. Модуль поиска направляет поиск отдельных каталогов в иерархии пользователя по заранее заданному шаблону до тех пор, пока не будет найдена запрошенная ветвь или пока алгоритм не будет исчерпан. Этот модуль вызывает координатора файлов для поиска в определенных каталогах и перехода к другим каталогам в иерархии.Пользователь может отменить эту процедуру поиска, предоставив свою собственную процедуру поиска при запуске или во время выполнения своего процесса.

Координатор файлов

Координатор файлов предоставляет все основные инструменты для управления записями в текущем рабочем каталоге пользователя. Функции, предоставляемые этим модулем, выполняют только самые примитивные операции и обычно дополняются более сложными процедурами системной библиотеки. Ниже приводится список (некоторых из этих операций.

  1. Создайте новую запись в каталоге.
  2. Удалить существующую запись.
  3. Переименовать запись.
  4. Возвращает информацию о статусе, относящуюся к конкретной записи.
  5. Изменить список контроля доступа для определенного филиала.
  6. Изменить рабочий каталог.

Всякий раз, когда пользователь желает выполнить какую-либо операцию с использованием координатора файлов, выполняется консультация с модулем управления доступом, чтобы определить, должна ли операция быть разрешена.

Поскольку большинство вызовов файлового координатора относятся к записям, содержащимся в рабочем каталоге пользователя, файловый координатор должен поддерживать указатель на этот каталог. Это делается путем сохранения имени дерева рабочего каталога в таблице рабочего каталога (WDT) для этого процесса.

Модуль управления каталогом

Когда файловый координатор желает выполнить поиск в рабочем каталоге пользователя, фактический поиск выполняется с помощью модуля управления каталогом.Этот модуль ищет в отдельном каталоге, заданном именем дерева, конкретную запись или группу записей. Фактический поиск в каталоге ограничен этим модулем, чтобы изолировать процесс рекурсии, который может потребоваться для поиска в данном каталоге.

Модуль управления каталогом выдает вызовы модулю управления сегментом, чтобы получить номер сегмента для каталога, для которого он имеет только имя дерева. Когда модуль управления каталогом получает этот номер сегмента и обращается к каталогу посредством адресации сегментов, может произойти сбой дескриптора, указывающий, что этот сегмент больше не активен.Если это произойдет, модуль управления сегментами попытается повторно активировать этот сегмент, пытаясь найти этот каталог в следующем вышестоящем каталоге с помощью имени дерева в таблице имен сегментов. Для этого модуль управления сегментами отправляет прямой вызов модулю управления каталогом для поиска отсутствующего каталога в следующем вышестоящем каталоге. После получения номера сегмента для вышестоящего каталога модуль управления каталогом может вызвать ошибку другого дескриптора при попытке поиска в этом каталоге.Этот процесс может продолжаться до тех пор, пока каталог не будет признан активным сегментом или пока не будет достигнут корень иерархии каталогов. Поскольку корень всегда известен модулю управления каталогом, глубина рекурсии конечна.

Модуль управления файлами

Модуль управления файлами предназначен для открытия и закрытия файлов для модуля управления сегментами. Файл называется открытым или активным , если он имеет соответствующую запись в таблице активных файлов (AFT). Если файл активен, соответствующая запись в таблице активных файлов предоставляет достаточно информации для управления последующими запросами ввода-вывода для этого файла.

Если файл неактивен, процедура открытия должна только открыть файл до запрошенного состояния и сделать соответствующую запись в активной таблице файлов. Если файл активен, у него может быть N пользователей, читающих, или 1 пользователь, читающих и записывающих, или N пользователей, совместно использующих данные (с использованием файла в качестве общей базы данных). Если запрошенное состояние несовместимо с текущим состоянием файла, текущий процесс должен быть заблокирован. [3] Например, если текущий пользователь желает прочитать стабильную копию файла, и в данный момент пользователь записывает в этот файл, запрошенное состояние (чтение) и текущее состояние (чтение и запись) называются быть несовместимым.

Если запрошенное состояние и текущее состояние файла оказываются совместимыми, количество пользователей, использующих файл в этом состоянии, увеличивается на единицу. Когда файл был успешно открыт модулем управления файлами (с разрешения модуля управления доступом), указатель на соответствующую запись в активной таблице файлов возвращается в вызывающую процедуру. Этот указатель используется для направления запросов на последующий ввод или вывод в правильный файл.

Модуль контроля доступа

Модуль управления доступом вызывается для оценки информации управления доступом для конкретной ветви, как определено в разделе 2.Этому модулю дается указатель на запись в каталоге для рассматриваемой ветви и код, указывающий тип выполняемой операции. Модуль управления доступом возвращает вызывающей процедуре единственный действующий режим. Эффективный режим - это режим, который управляет использованием файла по отношению к текущему пользователю или процессу. Вызывающая процедура использует этот режим, чтобы определить, разрешена ли запрошенная операция.

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

Модуль разметки страницы

Маркер страницы периодически прерывает текущий процесс и отмечает использование страницы, а также сбрасывает биты использования страницы [2] всех страниц, участвующих в текущем процессе.Страницы, уровень активности которых ниже динамически установленного порога активности, перечислены в таблице Page Out Table (POT) как вероятные кандидаты на удаление, когда потребуется место.

Модуль управления страницами

Управление передается модулю управления страницами посредством ошибки отсутствия страницы в таблице страниц, используемой текущим процессом. Эта ошибка может указывать на то, что новая страница должна быть назначена из свободного хранилища или что существующая страница должна быть получена из активного файла. В любом случае свободная страница должна быть назначена, прежде чем что-либо еще может произойти.Если в настоящее время нет доступных страниц, первая страница, указанная в таблице вывода страниц, выгружается. Если в таблице вывода страниц нет, случайная страница подходящего размера удаляется.

Если должна быть прочитана новая страница, запись в таблице страниц для отсутствующей страницы содержит указатель на соответствующую запись в таблице состояния сегмента и флаг, указывающий, должна ли эта страница считываться из исходного файла или из исполняемого файла. В любом случае указатель на соответствующий активный файл может быть получен из таблицы состояния сегмента.Этот указатель передается в качестве параметра модулю управления очередью ввода-вывода с запросом на чтение для восстановления правильной страницы в основной памяти.

Модуль управления очередью ввода-вывода

Модуль управления очередью ввода-вывода обрабатывает запросы ввода и вывода для конкретного активного файла. Вызывающая процедура определяет запрос на чтение или запись и указатель на запись в активной файловой таблице, которая соответствует желаемому файлу. Этот запрос помещается в соответствующую очередь для конкретного интерфейсного модуля устройства, который будет обрабатывать запрос.Затем модуль управления очередью вызывает этот интерфейсный модуль устройства, указывая, что в его очередь помещен новый запрос. Когда это будет сделано, модуль управления очередью возвращается к вызывающей процедуре, которая должна решить, блокировать ли себя до тех пор, пока запрос или запросы ввода-вывода не будут завершены.

Интерфейсные модули устройств

Для каждого типа вторичного запоминающего устройства, используемого базовой файловой системой, будет предоставлен интерфейсный модуль устройства. Модуль интерфейса устройства несет исключительную ответственность за стратегию работы с конкретным устройством, для которого он был написан.Любые особые соображения, относящиеся к конкретному устройству хранения, невидимы для всех модулей, кроме интерфейсного модуля для этого устройства.

Модуль интерфейса устройства также отвечает за назначение физических областей памяти, если это необходимо, на устройстве, для которого он был написан. Для выполнения этой функции интерфейсный модуль должен поддерживать записи всей памяти, уже назначенной на это устройство. Эти записи хранятся в таблицах назначения памяти , которые находятся на устройстве, к которому они относятся.

4.2 Другие модули файловой системы

Описанные ниже модули не считаются частью базовой файловой системы и не показаны на рис. 3. Однако эти модули считаются необходимой и неотъемлемой частью файловой системы в целом.

Модуль управления многоуровневым хранилищем

Модуль управления многоуровневым хранилищем работает как независимый процесс в системе Multics. Этот модуль собирает информацию о частоте использования файлов, которые в настоящее время активны в системе.Кроме того, этот модуль собирает информацию о перерасходе счетов из модуля учета вторичного хранилища.

Модуль управления хранилищем гарантирует, что достаточный объем вторичного хранилища всегда доступен для базовой файловой системы. Это достигается перемещением редко используемых файлов вниз в многоуровневом комплексе хранения. Этот модуль также перемещает наиболее часто используемые файлы на доступное вторичное запоминающее устройство самого высокого уровня.

Модули системы резервного копирования хранилища

Система резервного копирования хранилища состоит из пяти модулей, которые работают как независимые процессы.Эти модули выполняют функции, описанные в разделе 3.

  1. Модуль инкрементного дампа - единственная ответственность этого модуля заключается в подготовке лент инкрементного дампа всех новых или недавно измененных файлов.
  2. Модуль еженедельного дампа
  3. - Этот модуль запускается один раз в неделю для подготовки лент еженедельного дампа.
  4. Модуль извлечения - этот модуль извлекает файлы, которые были удалены из онлайн-системы хранения.
  5. Модуль аварийного восстановления
  6. - Этот модуль запускается после сбоя машины или системы для исправления любых несоответствий, которые могли привести к работе системы хранения в режиме онлайн.Поскольку система Multics не может быть безопасно запущена до тех пор, пока эти несоответствия не будут исправлены, аварийный модуль должен иметь возможность работать на необработанной машине.
  7. Модуль
  8. Catastrophe Reload - Этот модуль используется для перезагрузки содержимого онлайн-системы хранения с лент инкрементного и еженедельного дампа после сбоя машины или системы. Обычно этот модуль запускается только в том случае, если все попытки спасти содержимое оперативной системы хранения потерпели неудачу. Этот модуль должен быть способен работать на исходной машине или под управлением системы Multics.

Служебные и сервисные модули

Большая библиотека служебных модулей предоставляется как часть файловой системы. Эти модули предоставляют все необходимые функции для управления ссылками и переходами с использованием более примитивных функций, предоставляемых файловым координатором. Специальная группа служебных модулей предназначена для копирования информации, хранящейся в настоящее время в виде файла, на другой носитель ввода или вывода и наоборот. Следующие функции предоставляются как минимум:

  1. Файл на принтер
  2. Файл на карты
  3. Карточки в файл
  4. Лента к файлу
  5. Файл на магнитную ленту

Фактически эти модули просто помещают запрос пользователя в очередь для последующей обработки соответствующим сервисным модулем.Сервисный модуль выполняет запросы в своей очереди как независимый процесс. Как только запрос пользователя помещен в соответствующую очередь, управление возвращается вызывающей процедуре, хотя запрос еще не был выполнен.

5. Выводы

В этой статье представлена ​​универсальная файловая система вторичного хранилища. Были поставлены различные цели, которых должна достичь такая система, и система спроектирована таким образом, чтобы достичь этих целей. Такая система считается неотъемлемой частью эффективной интерактивной вычислительной системы.

6. Благодарность

Представленная здесь файловая система является результатом ряда вкладов множества людей, начиная с вычислительного центра Массачусетского технологического института, заканчивая проектом MAC и завершившимся настоящими усилиями.

Список литературы

  1. Ф. Дж. Корбато и В. А. Высоцкий, «Введение и обзор системы Multics», этот том.
  2. Э. Л. Глейзер, Дж. Ф. Кулер и Г. А. Оливер, «Системный дизайн компьютера для приложений с разделением времени», этот том.
  3. В. А. Высоцкий, Ф. Дж. Корбато и Р. М. Грэм, «Структура диспетчера Multics», этот том.
  4. Дж. Ф. Оссанна, Л. Э. Микус и С. Д. Дунтен, «Коммуникация и переключение ввода-вывода в мультиплексной вычислительной системе», этот том.
  5. Э. Дэвид-младший и Р. М. Фано, «Некоторые мысли о социальных последствиях доступных вычислений», этот том.

Дополнительные ссылки

  • К. В. Бахман и С. Б. Уильямс, "Универсальная система программирования для произвольного доступа к памяти", Труды осенней совместной компьютерной конференции 26, Spartan Books, Балтимор, 1964.
  • Дж. Б. Деннис и Э. К. Ван Хорн, «Семантика программирования для многопрограммных вычислений», Конференция ACM по языкам программирования, Сан-Димас, Калифорния, август 1965. Будет опубликовано в Comm. ACM.
  • A. W. Holt, "Организация программ и ведение записей для динамического распределения памяти", Comm. ACM 4, стр. 422-431, октябрь 1961 г.
  • Т. Х. Нельсон, "Файловая структура для сложной, изменчивой и неопределенной", Национальная конференция ACM, август.1965.
  • М. В. Уилкс, «Система хранения служебных программ для программистов», Computer Journal 7, pp. 180–184, октябрь 1964.

* Работа, описанная в данном документе, была поддержана (частично) Project MAC, M.I.T. исследовательская программа, спонсируемая Агентством перспективных исследовательских проектов Министерства обороны в рамках контракта с Управлением военно-морских исследований номер NONR-4102 (01).

Осенняя компьютерная конференция 1965 года


Контроль доступа к иерархической файловой системе (HFS)

В CA ACF2 Security есть два процесса, которые сайт может использовать для защиты иерархической файловой системы (HFS).Первый процесс является внутренним для системных служб z / OS UNIX и основан на модели безопасности UNIX. Второй процесс - это внешняя безопасность, и для защиты HFS используются стандартные правила безопасности CA ACF2. Эти процессы являются взаимоисключающими, поэтому ваш сайт должен выбрать, какой из них использовать.

Интерфейс безопасности HFS поддерживает CA ACF2 для zFS. Любая ссылка на поддержку интерфейса HFS в наборе документации CA ACF2 также подразумевает поддержку zFS.

Доступ к набору данных HFS из MVS

Если вы пытаетесь получить доступ к набору данных MVS, который представляет собой иерархическую файловую систему (HFS), через ISPF 3.2 или 3.4, возможно, вы получите сообщение «Сбой при получении». Расширенное сообщение гласит:

.

имя набора данных имеет неизвестные атрибуты, ПОЛУЧИТЬ RC = 12 шестнадцатеричное

Это происходит, если набор данных HFS не подключен к OMVS.

Когда запрашивается информация о наборе данных для не подключенного набора данных HFS, системные службы z / OS UNIX будут записывать информацию в каталог / tmp. Если пользователь, делающий запрос, не имеет доступа на запись, отображается сообщение об ошибке.

Чтобы избежать этой ошибки, необходимо убедиться, что разрешение общего доступа к каталогу / tmp разрешает любой доступ.Предлагается установить биты разрешений для каталога / tmp на 777, чтобы разрешить любой доступ.

Использование безопасности системных служб UNIX с CA ACF2 по-прежнему требует разрешения доступа с помощью правил ресурсов к каталогу / tmp.

Управление HFS с помощью модели безопасности UNIX

z / OS Файлы системных служб UNIX организованы в виде иерархии, как в системе UNIX. Все файлы являются членами каталога. Каждый каталог является членом другого каталога на более высоком уровне иерархии.Самый высокий уровень иерархии - это корневой каталог.

Безопасность каталогов и файлов файловой системы основана на модели безопасности UNIX. Каждому файлу и каталогу назначается собственный UID и собственный GID. Это назначение определяется и сохраняется в файловой системе, а не во внешнем продукте безопасности.

Обычно каждый файл или каталог сохраняет права доступа в виде четырех восьмеричных чисел nnnn. Первая позиция представляет специальные флаги доступа, а остальные три - категории разрешений.Флаги доступа включают липкий бит, setuid при выполнении и setgid при выполнении.

Остальные три категории пользователей могут получить доступ к каждому каталогу и файлу в HFS. Их:

  • Пользователь, владеющий файлом

  • Группа, владеющая файлом

  • Все остальные пользователи, определенные для системных служб z / OS UNIX

Три разных уровня доступа (READ, WRITE и EXECUTE) можно установить для любой из этих трех категорий.Например, разрешения могут быть определены таким образом, что владелец файла получает доступ на ЧТЕНИЕ и ЗАПИСЬ, член группы файла получает доступ только на ЧТЕНИЕ, а все остальные пользователи не имеют доступа ни на ЧТЕНИЕ, ни на ЗАПИСЬ.

В CA ACF2 необходимо определить UID для каждого пользователя системных служб z / OS UNIX и GID для каждой группы, которая обращается к системным службам z / OS UNIX. Вы также должны назначить группу по умолчанию для всех идентификаторов пользователей z / OS UNIX System Services и предоставить пользователям доступ к любым необходимым дополнительным группам.

Дополнительные сведения об иерархической файловой системе и настройке разрешений для файлов см. В следующих руководствах IBM:

  • Руководство пользователя системных служб z / OS UNIX

  • Планирование системных служб z / OS UNIX

Процессы, влияющие на безопасность HFS

При использовании модели безопасности UNIX различные параметры могут влиять на процесс проверки файла.В этом разделе описаны процессы и их влияние на безопасность или проверку файлов.

Списки управления доступом

(ACL) обеспечивают более детальный контроль над файловой системой HFS, чем собственная безопасность HFS. Чтобы активировать использование ACL в процессе проверки, единственное требование - указать HFSACL в записи GSO UNIXOPTS. По умолчанию ACL не активны (NOHFSACL)

Чтобы активировать ACL, используйте следующую команду ACF:

 

КОМПЛЕКТ УПРАВЛЕНИЯ (GSO) Сменить unixopts hfsacl

Чтобы активировать изменение, используйте следующую команду оператора:

 

F ACF2, ОБНОВИТЬ (UNIXOPTS)

Списки ACL создаются, удаляются и обслуживаются с помощью команды setfacl системных служб z / OS UNIX.Существующие ACL можно просмотреть с помощью команды getfacl z / OS UNIX System Services. Дополнительную информацию об этих командах см. В Справочном руководстве по IBM z / OS 1.3

USS Command

. ACL можно создавать и поддерживать, даже если они не активны (UNIXOPTS NOHFSACL). Чтобы пользователь мог выполнить команду setfacl, он должен быть одним из следующих:
  1. Владелец файла или каталога

  2. Суперпользователь

  3. Доступ для чтения к ресурсу UNIXPRIV SUPERUSER.FILESYS.CHANGEPERMS.

OMVS выдает вызов SAF при инициализации. Вызов SAF проверяет, определен ли профиль класса BPX.SAFFASTPATH ​​FACILITY. Если профиль определен, OMVS выполняет внутреннюю проверку битов разрешения вместо вызова внешнего диспетчера безопасности, минуя любой контрольный журнал нарушений. Это называется обработкой FASTPATH.

Чтобы отключить обработку FASTPATH, необходимо вставить следующую запись SAFDEF:

 

ВСТАВЬТЕ SAFDEF.OEFSTART FUNCRET (4) ID (OEFSTAUT) ИМЯ ЗАДАНИЯ (OMVS) РЕЖИМ (IGNORE) - RB (BPX-) RACROUTE (REQUEST = AUTH class = FACILITY ENTITY = BPX.SAFFASTPATH) REP

Теперь у вас есть возможность УСТАНОВИТЬ файловую систему или часть файловой системы с БЕЗОПАСНОСТЬЮ или без нее. Для использования команды MOUNT требуются права суперпользователя. Если файловая система смонтирована с параметром NOSECURITY, проверки доступа выполняются OMVS с использованием учетных данных системы вместо передачи учетных данных пользователя. OMVS обрабатывает учетные данные системы как суперпользователей, поэтому доступ всегда будет разрешен.

В сообщениях о монтировании нет указаний на то, что файл был смонтирован с опцией NOSECURITY. Всегда проверяйте член BPXPRMxx в parmlib, чтобы убедиться, что ни одна из файловых систем не монтируется NOSECURITY. Кроме того, ограничьте доступ к самой команде MOUNT, чтобы свести к минимуму возможность этого.

Команда смены владельца (CHOWN)

Команда CHOWN изменяет владельца файла (UID), группу (GID) или и то, и другое. Следующие пользователи могут выполнить эту команду:

  • Владелец файла

  • Суперпользователь

  • Пользователь с доступом к СУПЕРПОЛЬЗОВАТЕЛЮ.Ресурс FILESYS.CHOWN в классе UNIXPRIV

Вы можете работать в следующих режимах:

POSIX CHOWN RESTRICTED

Позволяет выполнять следующие действия:
  • Суперпользователи и пользователи с доступом SUPERUSER.FILESYS.CHOWN могут изменять UID и GID владельца файла.

  • Владелец файла может изменить GID на GID, который является одной из дополнительных групп владельца.

POSIX CHOWN UNRESTRICTED

Разрешает суперпользователям, пользователям с суперпользователем.Доступ к FILESYS.CHOWN и владельцам файлов для внесения изменений в UID и GID.

Чтобы POSIX CHOWN UNRESTRICTED был активен, в классе UNIXPRIV должно существовать правило CHOWN.UNRESTRICTED, а класс UNIXPRIV должен быть определен в записи INFODIR.

В POSIX CHOWN UNRESTRICTED владелец файла может выполнять следующие действия:

  • Измените UID файла на UID 0 (если у владельца есть доступ UPDATE к CHOWN.UNRESTRICTED).

  • Измените UID файла на другой ненулевой UID (если у владельца есть доступ READ к CHOWN.Без ограничений).

  • Измените GID файла на GID, который является одной из дополнительных групп владельца.

  • Измените GID файла на любой GID (если у владельца есть доступ READ к CHOWN.UNRESTRICTED).

Регистрационной записи с привилегией AUDIT разрешен доступ для поиска и чтения к каталогам в HFS. Это позволяет устанавливать биты опций аудита для любого файла в HFS, не требуя, чтобы все каталоги имели разрешения на поиск, разрешающие доступ аудитору.

Ограниченный доступ к ресурсам файловой системы UNIX

Владелец, группа и другие разрешения назначаются владельцем каталога или файла UNIX во время их создания. Если пользователь не является владельцем файла (UID) или не назначен группе (GID), которой разрешен доступ к файлу, то проверяются другие разрешения, чтобы определить, разрешен ли доступ.

Чтобы предотвратить проверку других разрешений и потенциально разрешить доступ, пользователь может быть определен как пользователь с ограниченным доступом.Это указывает на то, что доступ к каталогам и файлам UNIX не будет предоставлен, если у пользователя нет явной авторизации (через биты разрешения UID или GID и списки управления доступом). Это полезно, когда нет желания активировать HFS Security, но необходимо убедиться, что пользователи с ограниченным доступом не могут получить доступ к файлам HFS через биты разрешений в другой группе.

Определение пользователя с ограниченным доступом

Чтобы явно ограничить доступ пользователей к каталогам и файлам UNIX только на основе разрешений владельца или группы, но не других разрешений, администратор безопасности может выполнить следующие действия.

Для ограничения доступа пользователей к каталогам и файлам UNIX

  1. Назначьте привилегию RSTDACC идентификатору входа пользователя, выполнив следующие команды:

     

    КОМПЛЕКТ КРЫШКИ ИЗМЕНИТЬ логонид RSTDACC

    RSTDACC добавляется к логониду пользователя.

    У вас должна быть привилегия SECURITY, чтобы назначить привилегию RSTDACC. Если привилегия RSTDACC не назначена идентификатору входа, RSTDACC не будет отображаться в идентификаторе входа пользователя.

  2. Напишите правило ресурса для предотвращения доступа на чтение к UNIXPRIV (ОГРАНИЧЕН.FILESYS.ACCESS), введя следующие команды:

     

    УСТАНОВИТЬ РЕСУРС (UNIXPRIV) КОМП * МАГАЗИН $ КЛЮЧ (ОГРАНИЧЕННЫЙ) ТИП (UNI) FILESYS.ACCESS UID (uid) СЛУЖБА (ЧТЕНИЕ) ПРЕДУПРЕЖДЕНИЕ

    Создано правило ресурса.

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

Для отмены или отмены привилегии ограниченного доступа

  1. Удалите привилегию RSTDACC из логонид пользователя, введя следующие команды:

     

    КОМПЛЕКТ КРЫШКИ ИЗМЕНИТЬ логонид NORSTDACC

    Привилегия RSTDACC удалена.

  2. Напишите правило ресурса, чтобы предоставить хотя бы доступ для чтения к ресурсу UNIXPRIV (RESTRICTED.FILESYS.ACCESS), введя следующие команды:

     

    УСТАНОВИТЬ РЕСУРС (UNIXPRIV) КОМП * МАГАЗИН $ КЛЮЧ (ОГРАНИЧЕННЫЙ) ТИП (UNI) FILESYS.ACCESS UID (uid) СЕРВИС (ЧТЕНИЕ) РАЗРЕШИТЬ

    Создано правило ресурса.

Управление программами в среде UNIX

Когда средства BPX.DAEMON и BPX.SERVER активны, обработка авторизованных функций, таких как SETUID, требует, чтобы программы или исполняемые файлы были загружены из авторизованной библиотеки.В среде CA ACF2 эти авторизованные наборы данных представляют собой любую библиотеку в списке LPA, списке APF, LINKLIST, если LINKLIST был назначен как APF авторизованный, или GSO LINKLIST. Если программа загружается из HFS или набора данных MVS, отсутствующего в утвержденных списках, устанавливается флаг TCBNCTL, называемый «грязным битом». Это приводит к отказу авторизованных функций при попытке их использования в «грязной» среде.

Флаг TCBNCTL устанавливается в среде CA ACF2, только если активировано программное управление.По умолчанию этот процесс неактивен. Чтобы активировать его, вы должны переопределить PROGMCHK SAFDEF, который настроен на игнорирование. Чтобы переопределить этот SAFDEF, создайте следующий SAFDEF:

 

КОМПЛЕКТ УПРАВЛЕНИЯ (GSO) ВСТАВИТЬ SAFDEF.PROGMCHK ID (PROGMCHK) РЕЖИМ (GLOBAL) REP - RACROUTE (REQUEST = FASTAUTH REQSTOR = PROGMCHK SUBSYS = CONTENTS)

Этот SAFDEF активирует проверку для каждой выбранной программы. Перед активацией этого SAFDEF вы должны убедиться, что соответствующие правила программы действуют и что эти правила становятся резидентными через запись INFODIR.Вы можете сделать это, выполнив следующие действия:

  1. По умолчанию ресурсы класса PROGRAM проверяются под кодом типа PGM. Если вы хотите использовать код другого типа, введите следующую запись CLASMAP:

     

    КОМПЛЕКТ УПРАВЛЕНИЯ (GSO) ВСТАВИТЬ КЛАССИЧЕСКИЙ РЕСУРС ПРОГРАММЫ (ПРОГРАММА) ENTITYLN (8) ТИП (код типа)

  2. Проверка достоверности класса PROGRAM выполняется с помощью вызова FASTAUTH. Этот тип вызова требует, чтобы правила ресурсов были резидентными.Если он еще не включен в запись INFODIR, добавьте его к этой записи, введя следующее:

     

    КОМПЛЕКТ УПРАВЛЕНИЯ (GSO) ИЗМЕНЕНИЕ ТИПОВ ИНФОРМАЦИИ (R-RPGM)

    Если вы изменили код типа PGM по умолчанию на код другого типа, замените PGM в приведенном выше примере на код типа, который вы присвоили классу ресурсов PROGRAM.

  3. Создайте правила ресурсов типа PGM, необходимые для предоставления пользователям доступа к программам, которые они используют. Если вы хотите разрешить доступ к какой-либо программе и установить среду, аналогичную той, в которой была активирована проверка программ, вы можете ввести следующее правило ресурса:

     

    УСТАНОВИТЬ РЕСУРС (PGM) СОСТАВИТЬ * $ KEY (********) ТИП (PGM) UID (*) РАЗРЕШИТЬ

    Если вам нужны более конкретные элементы управления, напишите правило для каждой программы в вашей среде.Чтобы активировать все ранее описанные шаги, введите следующие команды оператора:
     

    F ACF2, ОБНОВИТЬ (ВСЕ) F ACF2, ПЕРЕСТРОЙКА (PGM)

Когда исполняемый файл или программа запрашивается в среде OMVS, OMVS находит исполняемый файл в HFS и загружает его оттуда, если не включен «липкий бит». Если для исполняемого файла установлен бит закрепления, OMVS использует обычную обработку загрузки MVS. Чтобы включить липкий бит с помощью команды OMVS chmod, пользователь должен владеть файлом или быть суперпользователем.

Если исполняемый файл или программа должны быть загружены непосредственно из HFS, тогда для файла должен быть установлен расширенный атрибут «Программа», чтобы он считался управляемой программой. Это можно сделать с помощью команды OMVS extattr, однако для использования этой команды требуется доступ к ресурсу BPX.FILEATTR.PROGCTL. Чтобы настроить правило, разрешающее это, добавьте следующую строку правил в правило ресурса BPX FACility:

 

UID FILEATTR.PROGCTL (chmod_user) РАЗРЕШИТЬ

Управление HFS с помощью CA SAF HFS Security

z / OS объединяет операционные системы MVS и UNIX на одной аппаратной платформе.Хотя существует некоторая совместимость между MVS и UNIX, каждая среда сохраняет свои собственные отдельные структуры данных и методы управления доступом.

Данные UNIX хранятся в иерархической файловой системе (HFS). С точки зрения UNIX, HFS содержит множество дискретных файлов данных. С точки зрения MVS, HFS - это один набор данных, которым можно управлять только как один набор данных. Другими словами, MVS может контролировать доступ ко всей файловой системе, но не к отдельным файлам в HFS.

Файлы

HFS защищены битовыми настройками прав доступа к файлам.Они устанавливаются, когда владелец файла создает файл. Централизованное администрирование может выполнять только суперпользователь, привилегия пользователя, которая дает гораздо больше полномочий, чем просто администрирование безопасности. Ресурсы z / OS защищены правилами доступа и ресурсов, которые обычно устанавливаются администраторами безопасности заранее. Администраторы безопасности могут работать в децентрализованной среде.

CA SAF HFS безопасность преодолевает недостатки встроенной безопасности UNIX, обеспечивая единую точку управления доступом, администрирование и создание отчетов для ресурсов MVS и UNIX.Службы CA ENF представляют события доступа в CA ACF2 для проверки. Администраторы используют знакомые команды и правила для защиты файлов и функций UNIX, ограничивая доступ на основе строки UID CA ACF2 вместо номеров UID или GID UNIX. Журналы доступа к HFS и нарушения сообщаются в стандартных отчетах CA ACF2.

В следующих разделах объясняется:

  • Защита доступа к файлам HFS с использованием правил ресурсов

  • Защита HFS (система и файл) Реализация

  • Утилита создания правил CA SAF HFS

  • Утилита изменения безопасности CA SAF HFS

При использовании безопасности CA SAF HFS игнорируется защита битов прав доступа к файлам, а также права суперпользователя на доступ к любому файлу.Доступ к файлам подтверждается службой безопасности CA ACF2 с использованием правил ресурсов. Можно использовать все преимущества правил ресурсов, включая маскирование, NEXTKEY, область видимости,% CHANGE и создание отчетов. Доступны определенные расширения, которые позволяют определять пользовательские каталоги и позволяют пользователям поддерживать правила для своих файлов.

Структура имен путей HFS представляет проблему для продуктов внешней безопасности. Имя пути может иметь длину до 1023 символов, за исключением случаев, когда оно используется в ключевом слове JCL PATH =, где ограничение составляет 255 символов.Имя пути также чувствительно к регистру и может содержать специальные символы. Чтобы позволить внешней безопасности проверять файлы HFS, требуются определенные манипуляции с именами путей. Преимущества повышенной безопасности и единого администрирования, безусловно, делают перевод имен файлов приемлемым.

Перед проверкой все имена путей при необходимости обрезаются до 255 символов. Точка выхода (HFSEXIT) предоставляется для использования, когда имена файлов находятся в путях, длина которых превышает 255 символов.Ваш сайт может использовать выход, чтобы дать значимое имя. Для получения дополнительной информации см. HFS Security Exit (HFSEXIT).

Имена путей преобразуются в верхний регистр, если ваш сайт не вставляет запись GSO CLASMAP для класса HFSSEC и не указывает ключевое слово MIXED, чтобы указать, что должны использоваться имена ресурсов в смешанном регистре. Используйте подкоманду SHOW CLASMAP команды ACF, чтобы определить, указывает ли класс HFSSEC MIXED. Для получения дополнительной информации см. GSO-запись CLASMAP и ключевое слово MIXED.

Обработка правила ресурсов CA ACF2 рассматривает символ точки в качестве разделителя.Этот разделитель используется при написании расширенных правил ресурсов, то есть для обеспечения безопасности имен ресурсов, содержащих более сорока символов. Однако в именах путей в качестве разделителя используется косая черта. Перед проверкой файла в имени пути все символы косой черты, за исключением первого, будут переведены в разделитель точки. Остальные специальные символы будут переведены в знак доллара ($). К ним относятся символы, которые используются в качестве маскирующих символов в правилах ресурсов. Если не перевести эти символы, это может привести к нежелательным результатам.К специальным символам относятся точка, звездочка, тире, плюс, пробел и кавычки. Предусмотрена точка выхода, с помощью которой можно дополнительно изменить любой символ в соответствии с особыми потребностями, за исключением символа косой черты, который всегда будет преобразован в разделитель точки.

Ниже приведены некоторые примеры преобразования имени пути:

/ bin / su

Управление доступом для переключения команды пользователя.

/ u / user01 / proj1 / file1.txt

Определите набор правил для user01.

/ usr / sbin / mknod

Разрешить системным программистам создавать специальные символьные файлы.

/BIN.SU

$ ТИП КЛЮЧА (/ BIN) (HFS) SU UID (sysprog) ALLOW

/U.USER01.PROJ1.FILE1$TXT

$ KEY (/ U) TYPE (HFS) USER01.- UID (usera) РАЗРЕШИТЬ

/ USR.SBIN.MKNOD

$ ТИП КЛЮЧА (/ USR) (HFS) SBIN.MKNOD UID (sysprog) РАЗРЕШИТЬ

Битовые программы доступа Siteuid

В обычной HFS, когда выполняется программа или исполняемый файл с установленным битом разрешения seteuid, процесс seteuid изменяет UID с фактического пользователя на UID владельца файла. Это позволяет пользователям получать доступ к файлам с разными разрешениями, отличными от их собственных.

При обработке CA ACF2 HFS доступ к файлу осуществляется на основе UID лица, осуществляющего доступ к файлу.Однако из-за обработки seteuid, описанной выше, поддержка CA ACF2 все еще позволяет это. Когда поддержка CA ACF2 HFS определяет, что бит seteuid установлен, она проверяет, совпадает ли действующий UID с UID владельца файла. Если они совпадают, доступ разрешен. Если они не совпадают, выполняется обычная проверка ресурса.

Когда к фактическому файлу обращаются через символическую ссылку, имя файла, переданное CA ACF2, было преобразовано в фактическое имя файла файла, и проверка выполняется на основе этого фактического имени файла.Для большинства ситуаций проверки этого достаточно. Однако в следующих случаях CA ACF2 проверяет саму ссылку, а не имя файла:

 

unlink (удалить символическую ссылку) переименовать (изменить имя одной символической ссылки на другое) readlink (прочтите символическую ссылку, чтобы определить, на что она указывает) lchown (сменить владельца ссылки)

файлов HFS в одной системе могут быть доступны из других систем в сисплексе. Дополнительные сведения и подробности об общей HFS см. В Руководстве по планированию системных служб z / OS UNIX.

Запись правил HFS CA ACF2 связана с тем, как системные службы z / OS UNIX указывают имя пути в совместно используемом сисплексе HFS. Имя пути теперь содержит системное имя системы, которой принадлежит файл. Например, ссылаясь на приведенные выше примеры преобразования имени пути, доступ к команде su в системе XE77 будет иметь исходное имя пути / XE77 / bin / su. Это будет преобразовано в имя пути для CA ACF2 /XE77.BIN.SU. Это дает нам правило ресурса, подобное следующему:

 

$ ТИП КЛЮЧА (/ XE77) (HFS) БИН.SU UID (sysprog) РАЗРЕШИТЬ

Еще одно соображение при проверке файлов HFS - это способ проверки файлов пользователей. Пользовательские файлы - это те файлы, которые находятся под записью каталога, представляющей конкретного пользователя. Безопасность CA SAF HFS предоставляет пользователям возможность поддерживать свои собственные правила ресурсов, может генерировать имена ресурсов, которые могут быть идентифицированы как существующие в каталоге пользователя, и может обходить проверку доступа пользователя к файлам в собственном каталоге пользователя.

Право собственности на наборы данных MVS определяется с помощью квалификатора высокого уровня набора данных.В децентрализованной среде безопасности пользователи могут создавать правила для защиты своих наборов данных. Эта концепция была перенесена в защиту файлов HFS. Когда GSO RULEOPTS указывает параметр NOCENTRAL, пользователи могут поддерживать и хранить свои собственные правила ресурсов HFS. Право собственности определяется в $ KEY наличием идентификатора пользователя с префиксом $$. Этот префиксный ИД пользователя должен быть единственным значением в $ KEY. Например, USER01 может поддерживать правило ресурса HFS с помощью $ KEY ($$ USER01). ИД пользователя должен быть определен как пользователь OMVS.

Несмотря на то, что проверка может быть направлена ​​к правилу $$ идентификатора пользователя с помощью NEXTKEY, как показано в примере в предыдущем разделе, Преобразование имени пути, доступна еще одна возможность, которая автоматически переводит правило в формат идентификатора пользователя $$ во время проверки. Эту возможность можно использовать, если все пользовательские каталоги привязаны к одному и тому же месту в файловой системе. Программа выхода установки определяет это местоположение для безопасности CA SAF HFS как точку монтирования каталога пользователя. Обычно привязка пользовательских каталогов находится в точке монтирования / u /.В этом случае, расширяя предыдущий пример, путь /u/user01/proj1/file1.txt преобразуется в $$ USER01.PROJ1.FILE1 $ TXT. Даже если каталоги пользователей не привязаны к одному центральному расположению, выход можно использовать для создания формата идентификатора пользователя $$ для ресурса во время проверки. По умолчанию путь к каталогу пользователя не распознается, и ресурс не переводится в формат $$ userid

.

Другой доступный вариант - это возможность для пользователей получать доступ к файлам, которые находятся в их собственном пользовательском каталоге, без проверки этого файла.Другими словами, пользователи всегда могут получить доступ к своим файлам. Эта опция требует, чтобы точка привязки каталога пользователя была определена с помощью выхода установки. Выход возвращает индикатор, указывающий, что опция владения файлом активна. Если продолжить пример, если эта опция была активна, проверка будет пропущена, когда USER01 обращается к /u/user01/proj1/file1.txt. По умолчанию у пользователей нет автоматического доступа к своим файлам.

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

Помимо доступа к файлам HFS, пользователям может потребоваться доступ к каталогам. Пользователю требуется доступ на ЧТЕНИЕ к каталогу, чтобы просмотреть содержимое этого каталога. При написании набора правил вы выделяете строку правил, защищающую каталог, от строк правил, защищающих файлы в каталоге, не используя расширенный ключ в строке правила. Например, правило, позволяющее пользователям читать каталог / BIN, но разрешать доступ EXECUTE только к файлам, содержащимся в этом каталоге:

 

$ КЛЮЧ (/ BIN) T (HFS) UID (hfsusers) СЕРВИС (ПРОЧИТАТЬ, ВЫПОЛНИТЬ) РАЗРЕШИТЬ - UID (hfsusers) СЕРВИС (ВЫПОЛНИТЬ) РАЗРЕШИТЬ

Файлы, содержащиеся в корневом каталоге, должны быть указаны как значение $ KEY в отдельном наборе правил, то есть они не могут быть указаны как расширенная строка правила в корневом наборе правил $ KEY (/).Следовательно, единственная допустимая строка правила для корневого набора правил $ KEY (/) - это та, которая разрешает доступ для чтения к самому каталогу. Ниже показан набор правил, необходимый для корневого каталога, и примерный набор правил, разрешающий доступ для чтения (READ) и записи (UPDATE), а также для создания и удаления (ADD) доступа к файлу / корневому файлу:

 

$ КЛЮЧ (/) T (HFS) UID (hfsusers) СЕРВИС (ЧТЕНИЕ) РАЗРЕШИТЬ $ КЛЮЧ (/ КОРНЕВОЙ ФАЙЛ) T (HFS) UID (hfsusers) СЕРВИС (ДОБАВЛЕНИЕ, ЧТЕНИЕ, ОБНОВЛЕНИЕ) РАЗРЕШИТЬ

Правила, написанные для защиты файловых ресурсов HFS, должны указывать ключевое слово SERVICE для определения типа доступа к файлу.Если ключевое слово SERVICE не используется, подразумевается

все

доступа. Ключевые слова SERVICE:

EXECUTE

Позволяет выполнить доступ к файлу, обычно к файлу программы.

ЧТЕНИЕ

Разрешает доступ для чтения к файлу.

ОБНОВЛЕНИЕ

Разрешает запись в файл.

ДОБАВИТЬ

Позволяет создавать и удалять файлы.

УДАЛИТЬ

Специальный доступ, не используемый для обычной проверки доступа к файлам. Это используется с функцией безопасности HFS, чтобы позволить пользователю изменять атрибуты файла.

CA SAF Защита HFS использует ускоренную проверку ресурсов. По этой причине правила ресурсов HFS должны быть определены как резидентные посредством использования записи GSO INFODIR. Кроме того, для проверки файла HFS не обрабатываются выходы CA ACF2 Resource Prevalidation (RSCXIT1) и Resource Postvalidation (RSCX172).

Записи аудита, созданные при доступе к файлам HFS, то есть записи нарушений, трассировки и регистрации, доступны через те же средства, что и все другие записи ресурсов, а именно ACFRPTRV. Помимо всех стандартных элементов, указывается исходное неизмененное имя пути длиной до 256 символов. При использовании собственных отчетов исходное имя пути можно найти в поле записи SMF ACVMFXKY.

Служба доступа может использоваться системными службами z / OS UNIX для предварительного определения того, имеет ли процесс доступ к определенному файлу или каталогу.Рассматриваемый процесс не пытается получить доступ к файлу или каталогу; скорее, система системных служб z / OS UNIX просто проверяет, может ли процесс получить доступ к файлу или каталогу. Когда служба доступа используется таким образом, обработка CA ACF2 не создает записи SMF для ACFRPTRV.

Помимо защиты доступа к файлам, можно также защитить функции HFS. Эти функции могут быть системными действиями, такими как установка ptrace или приоритета задания, или они могут быть связаны с файлами, например, изменение режима файла или настроек аудита.

Системная функция защищена правилом класса FACILITY, а функция, относящаяся к файлам, защищена комбинацией правила класса FACILITY и правила файлового ресурса HFS. Следуя этому подходу, изменения атрибутов файла могут быть разрешены на глобальном уровне или ограничены конкретным файлом.

Формат имени ресурса для правил HFS FACILITY:

 

BPX.CAHFS.функция

Пример правила:

 

$ КЛЮЧ (BPX) ТИП (FAC) CAHFS.UID функции (пользователь) РАЗРЕШИТЬ

Значения для функции

перечислены в следующем разделе, Системные функции.

Для выполнения системной функции пользователю требуется доступ на ЧТЕНИЕ к соответствующему правилу ОБЪЕКТА:

BPX.CAHFS.CHANGE.FILE.MODE

Позволяет пользователю изменять любую информацию о режиме файла. Это включает в себя изменения настроек прав доступа к файлам, установку индикаторов UID или GID выполнения, установку «липкого» бита и ведение списков контроля доступа.Собственные настройки разрешений z / OS UNIX используются для проверки, только когда CA SAF HFS неактивен.

BPX.CAHFS.CHANGE.PRIORITY

Позволяет пользователю изменять приоритет планирования процесса, группы процессов или пользователя. Системные службы z / OS UNIX требуют, чтобы пользователь был суперпользователем для использования этой функции.

BPX.CAHFS.SET.PRIORITY

Позволяет пользователю установить приоритет планирования процесса, группы процессов или пользователя. Системные службы z / OS UNIX требуют, чтобы пользователь был суперпользователем для использования этой функции.

BPX.CAHFS.SET.RLIMIT

Позволяет пользователю установить лимит ресурсов для вызывающего процесса.

BPX.CAHFS.MOUNT

Позволяет пользователю монтировать файловые системы. Системные службы z / OS UNIX требуют, чтобы пользователь был суперпользователем для использования этой функции.

BPX.CAHFS.UNMOUNT

Позволяет пользователю удалить виртуальную файловую систему. Системные службы z / OS UNIX требуют, чтобы пользователь был суперпользователем для использования этой функции.

BPX.CAHFS.USERMOUNT

Разрешить непривилегированному пользователю монтировать файловую систему.Это отличается от поддержки BPX.CAHFS.MOUNT тем, что системные службы Unix добавляют дополнительные критерии, позволяющие пользователю монтировать файловую систему. Дополнительные критерии включают необходимость монтировать в пустой каталог, иметь разрешение на монтирование каталога точки и монтируемую файловую систему. Полный список дополнительных критериев, налагаемых системными службами Unix, приведен в документе IBM

z / OS Unix System Services Planning Guide

. Чтобы удовлетворить требование о том, что пользователь должен владеть или иметь разрешения на монтируемую файловую систему и каталог точки монтирования, требуются два новых правила.Пользователь должен иметь доступ ADD к правилу в классе HFS, где:
  • Правило представляет набор данных файловой системы

Класс HFS, где правило представляет направление точки монтирования

Например, если пользователь BOB имеет возможность монтировать OMVS.HFS.BOBFILE в точке монтирования / user / bob, вам понадобятся следующие два правила:

 

$ КЛЮЧ (OMVS.HFS.BOBFILE) ТИП (HFS) UID (BOB) СЕРВИС (ДОБАВИТЬ) РАЗРЕШИТЬ Тип $ KEY (/USER.BOB) (HFS) UID (BOB) СЕРВИС (ДОБАВИТЬ) РАЗРЕШИТЬ

BPX.CAHFS.USERUNMOUNT

Позволяет непривилегированному пользователю отключать файловую систему. Системные службы Unix гарантируют, что непривилегированный пользователь не сможет размонтировать файловую систему, которую пользователь не монтировал.

BPX.CAHFS.PTRACE

Позволяет пользователю управлять и отлаживать другой процесс. Хотя для использования этой функции пользователь не должен быть определен как суперпользователь, доступ к этому ресурсу не дает пользователю больше полномочий, чем мог бы иметь суперпользователь. В доступе к функции будет отказано, если пользователь попытается отладить программу, работающую с SETUID или SETGID, то есть программу, переключающую идентификацию пользователя.

BPX.CAHFS.CREATE.LINK

Позволяет пользователю создать жесткую ссылку на существующий файл. Жесткая ссылка - это, по сути, другое имя для тех же данных файла. Если исходный файл удален, жесткая ссылка по-прежнему указывает на данные файла. В дополнение к этому ресурсу пользователю также требуется доступ СЕРВИС (ДОБАВЛЕНИЕ) к правилу файлового ресурса HFS для файла ссылки. Важный! При доступе к данным, связанным с жесткой ссылкой, служба CA ENF / USS запрашивает имя файла у z / OS UNIX Services.Возвращаемое имя файла может быть именем жесткой ссылки или исходным именем файла независимо от фактического пути, к которому осуществляется доступ. Невозможно предсказать, какое имя будет возвращено. Поэтому, когда существует жесткая ссылка, вам может потребоваться поддерживать правила как для имени ссылки, так и для исходного имени.

BPX.CAHFS.CREATE.EXTERNAL.LINK

Позволяет пользователю создать внешнюю ссылку на объект вне файловой системы, например на набор данных z / OS MVS. Внешняя ссылка - это файл, содержащий имя внешнего объекта.Если внешний объект удален, внешняя ссылка по-прежнему будет содержать имя несуществующего объекта.

BPX.CAHFS.CREATE.SYMBOLIC.LINK

Позволяет пользователю создать символическую ссылку на существующий файл. Символьная ссылка - это файл, содержащий имя другого файла. Если исходный файл удаляется, данные файла удаляются, но символическая ссылка по-прежнему содержит указатель на несуществующий файл. Символические имена ссылок проверяются при создании и удалении ссылки. Все другие обращения подтверждаются исходным именем файла.В дополнение к этому ресурсу пользователю также требуется доступ СЛУЖБЫ (ДОБАВЛЕНИЕ) к правилу файлового ресурса HFS как для исходного файла, так и для файла ссылки.

Функции, связанные с файлами, могут быть защищены на различных уровнях детализации. Это достигается путем определения наивысшего уровня доступа пользователя к ресурсу ОБЪЕКТА. Для этого используется ключевое слово SERVICE правила ресурса FACILITY. В зависимости от определенного уровня СЕРВИС пользователю может быть разрешено выполнение функции, может быть отказано или пользователю может потребоваться доступ к правилу файлового ресурса HFS для разрешения функции.Следующие действия выполняются на основе значения СЕРВИС:

ДОБАВИТЬ

Пользователю разрешено выполнять эту функцию для всех файлов.

УДАЛИТЬ

Пользователю разрешено выполнять функцию, если у пользователя также есть доступ СЕРВИС (УДАЛЕНИЕ) к правилу файловых ресурсов HFS. Уровень обслуживания DELETE не используется при обычном доступе к файлам.Здесь он используется для предоставления дополнительных элементов управления файловыми функциями.

ОБНОВЛЕНИЕ

Обработка такая же, как и для УДАЛЕНИЯ.

ПРОЧИТАТЬ

Пользователю разрешено выполнять функцию, если у пользователя также есть доступ СЕРВИС (УДАЛЕНИЕ) к правилу файловых ресурсов HFS или если пользователь считается владельцем файла. Это право собственности, как определено в безопасности CA SAF HFS, а не UID файла UNIX.

Нет

Если у пользователя нет доступа к правилу ресурса FACILITY, функция запрещена.

Поскольку отсутствие ключевого слова SERVICE в правиле подразумевает

всех

служб, обязательно укажите SERVICE во всех правилах FACILITY файловой функции, чтобы случайно не разрешить больший доступ к функциям, чем предполагалось.

Настройки прав доступа к файлу HFS и владение UID / GID не используются для проверки, когда активна безопасность CA SAF HFS. Однако следующие ресурсы ограничивают изменение этих параметров в тех случаях, когда их необходимо поддерживать.

FACILITY Ресурсы для файловых функций

Ниже приведены ресурсы FACILITY файловой функции:

BPX.CAHFS.CHANGE.FILE.ATTRIBUTES

Позволяет пользователю изменять расширенные атрибуты файла, такие как авторизация APF и управление программой. Собственные службы z / OS UNIX будут вызывать вызов ресурса FACILITY, чтобы определить авторизацию для установки определенного атрибута, но не для определенных файлов. Использование этого ресурса файловой функции обеспечивает дополнительный контроль вплоть до файлового уровня.Имена ресурсов FACILITY, используемые собственными службами z / OS UNIX: BPX.FILEATTR.APF и BPX.FILEATTR.PROGCTL.

BPX.CAHFS.CHANGE.FILE.AUDIT.FLAGS

Файлы HFS содержат два набора флагов аудита: один может быть установлен обычным пользователем, а другой - только аудитором. Этот ресурс позволяет пользователю изменять флаги пользовательского аудита в файле. Флаги аудита-аудита могут быть установлены только пользователем с логонидом AUDIT или привилегией SECURITY с незаданной областью. Когда аудитор изменяет флаги аудита файла, проверка не выполняется.

BPX.CAHFS.CHANGE.FILE.FORMAT

Позволяет пользователю изменять формат файла. Изменения включают определение разделителей текстовых данных или формата двоичного файла.

BPX.CAHFS.CHANGE.FILE.MODE

Позволяет пользователю изменять любую информацию о режиме файла. Это включает в себя изменения настроек прав доступа к файлам, установку индикаторов UID или GID выполнения, установку «липкого» бита и ведение списков контроля доступа. Собственные настройки разрешений z / OS UNIX используются для проверки только в том случае, если защита CA SAF HFS неактивна.

BPX.CAHFS.CHANGE.FILE.MODE.STICKY

Позволяет пользователю установить «липкий» бит в информации о режиме файла. Бит «залипания» заставляет программу загружаться из библиотек MVS вместо HFS. При установке этого бита пользователю также требуется доступ к ресурсу BPX.CAHFS.CHANGE.FILE.MODE.

BPX.CAHFS.CHANGE.FILE.MODE.EUID

Позволяет пользователю установить индикатор UID выполнения в информации о режиме файла. Когда этот индикатор установлен, программа запускается под UNIX UID владельца файла, а не под UID пользователя, запускающего программу.При установке этого индикатора пользователю также требуется доступ к ресурсу BPX.CAHFS.CHANGE.FILE.MODE.

BPX.CAHFS.CHANGE.FILE.MODE.EGID

Позволяет пользователю установить индикатор GID выполнения в информации о режиме файла. Когда этот индикатор установлен, программа запускается под UNIX GID владельца файла, а не под GID пользователя, запустившего программу. При установке этого индикатора пользователю также требуется доступ к ресурсу BPX.CAHFS.CHANGE.FILE.MODE.

BPX.CAHFS.ИЗМЕНИТЬ.ФАЙЛ.ВЛАДЕЛЬЦА

Позволяет пользователю изменять настройку UID владельца файла. Собственные настройки владения z / OS UNIX используются для проверки только в том случае, если защита CA SAF HFS неактивна.

BPX.CAHFS.CHANGE.FILE.GROUP

Позволяет пользователю изменять настройку GID владельца файла. Собственные настройки владения z / OS UNIX используются для проверки только в том случае, если защита CA SAF HFS неактивна.

BPX.CAHFS.CHANGE.FILE.TIME

Позволяет пользователю изменить время последнего доступа или модификации на текущее или указанное пользователем время.Если необходимо установить текущее время и у пользователя есть доступ на запись к файлу, функция разрешена. Если у пользователя нет доступа на запись или необходимо установить время, указанное пользователем, доступ к этому ресурсу ОБЪЕКТА должен быть разрешен.

В следующем примере показаны правила, позволяющие Тельме изменять режим файла и владельца для всех файлов. Луизе разрешено изменять файловый режим только для тех файлов, которые находятся в определенном каталоге, но не разрешено изменять владельца файла в любом файле:

 

$ КЛЮЧ (BPX) ТИП (FAC) CAHFS.CHANGE.FILE.MODE UID (thelma) СЕРВИС (ДОБАВИТЬ) РАЗРЕШИТЬ CAHFS.CHANGE.FILE.MODE UID (louise) СЕРВИС (УДАЛИТЬ) РАЗРЕШИТЬ КЛЮЧ $ (BPX) ТИП (FAC) CAHFS.CHANGE.FILE.OWNER UID (thelma) СЕРВИС (ДОБАВИТЬ) РАЗРЕШИТЬ $ KEY (/ определенный) ТИП (HFS) справочник.- UID (louise) СЕРВИС (УДАЛИТЬ) РАЗРЕШИТЬ

Внедрить CA SAF HFS Security

CA SAF HFS security - это приложение CA ENF / USS (системные службы UNIX). Это приложение безопасности активируется, когда выполняются оба этих условия:

  1. Включите модули CAIENF DCM для обработки событий.

  2. CA SAF Защита HFS включена.

Этапы реализации следующие:

  1. Определите, требуется ли обработка выхода для преобразования имени пути, определения пути пользователя или для включения владения файлом. Подробнее об обработке выхода см. Ниже. При использовании выхода соберите и скомпонуйте код выхода, используя образец пользовательского мода SMP / E, найденный в члене CAX1JCL0 UM80001.

  2. Определите правила ресурсов файлов и функций HFS.Рекомендуется определить все описанные выше правила ресурсов функций. Предоставляется служебная программа для помощи в создании этих правил ресурсов. Подробнее см. Ниже.

  3. Если вы используете функцию владения файлами пользователя в системе безопасности CA SAF HFS, также определяете правила для пользователей или в децентрализованной среде безопасности, уведомляйте пользователей, что они должны писать правила для себя.

  4. Определите правила файла HFS как резидентные, используя запись GSO INFORDIR:

     

    НАБОР C (GSO) CH INFODIR TYPES (R-RHFS)

  5. Убедитесь, что соответствующий уровень CA ENF доступен для поддержки ENF / USS.Это обеспечивается CA Common Services.

    Примечание:

    У вас должен быть установлен CA Common Services на уровне 9901 или выше.
  6. Запущенная задача ENF должна быть действующим пользователем OMVS. Если этого не сделать, выдается сообщение CARR014E. Убедитесь, что логонид ENF указывает группу и что группа определена в записи профиля OMVS GROUP. Определите запись профиля OMVS USER с UID (0) для идентификатора входа ENF:

     

    УСТАНОВИТЬ ПРОФИЛЬ (ПОЛЬЗОВАТЕЛЬ) DIV (OMVS) ВСТАВИТЬ enf UND (0)

  7. При использовании CA ENF r12 DCM больше не хранятся в самой базе данных.Вместо этого DCM теперь считываются и обрабатываются во время запуска ENF. Чтобы включить модули CAIENF DCM для обработки событий, модули DCM должны быть указаны с помощью оператора DCM в элементе конфигурации ENF ENFPARM. Подробные сведения о спецификации оператора DCM см. В разделе Параметры управления CAIENF в CA Common Services. Перед CA ENF r12 убедитесь, что соответствующие модули DCM связаны с базами данных ENF. Установите следующие модули DCM в базу данных ENF с помощью служебной программы ENFDB: CARRDCM0 и J163DCM0.Модули DCM поступают от следующего CAX1LINK:
    • J163DCM0 находится в CAI.CAX1LINK

    • CARRDCM0 находится в общих службах CA USS CAX1LINK

    Образец JCL для перемещения ACF2 J163DCM0 можно найти в библиотеке CAI.CAX1JCLS в члене ENFUSS. Его также можно изменить для CA Common Services CARRDCM0. См. CA Common Services для получения подробной информации о программе CAS9DB.

    Если вы ранее установили J163DCM0 DCM (модуль управления данными) в базу данных ENF, вам не нужно повторно выполнять этот шаг.

  8. Определение класса VLF для использования в качестве кэша может повысить производительность ENF / USS. Размер кеша определяется спецификацией MAXVIRT. Вы можете приблизительно определить количество записей в кэше, разделив определенный объем хранилища VLF на средний размер ваших имен путей. Добавьте следующее к вашему текущему члену COFVLFxx в SYS1.PARMLIB:

     

    ИМЯ КЛАССА (CAENFU) / * ENF / USS путь кеширования * / EMAJ (PATHCACHE) / * Основное имя * / MAXVIRT (256) / * 1 мегабайт * /

    См. CA Common Services для получения дополнительной информации об определении класса VLF.

  9. Добавление атрибута NON-CNCL к идентификатору входа BPXOINIT во время начального тестирования позволит OMVS успешно инициализироваться без нарушений. Как только соответствующие правила введены в действие, атрибут NON-CNCL должен быть удален.

  10. Следующее сообщение выдает CA ENF / USS при запуске ENF, когда установлены перехватчики безопасности CA SAF HFS:

     

    CARR036I - SAFHFINT / J165 Теперь инициализировано

  11. CA SAF Защита HFS должна быть включена.Если запись GSO UNIXOPTS указывает HFSSEC, тогда безопасность CA SAF HFS будет включена после запуска CA ENF / USS. Запись GSO в UNIXOPTS по умолчанию имеет значение NOHFSSEC. Команда F ACF2, HFS (STATUS | ENABLE | DISABLE) может использоваться для включения, отключения и проверки состояния CA SAF HFS Security.
  12. Запустите ACFRPTRV на этапе внедрения. Просмотрите нарушения и журналы для типов ресурсов HFS и FAC и создайте соответствующие правила. Если это было сделано в предыдущем выпуске CA ACF2, этот шаг можно пропустить.

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

Выход должен быть реентерабельным и иметь возможность запускать AMODE (31) и RMODE (ANY). Выход преобразования имени пути (SAFHFUSR) всегда будет вызываться в AMODE (31) независимо от AMODE, в котором был вызван исходный вызов.Выход может быть определен в записи GSO EXITS или может быть связан вместе с загрузочным модулем SAFHFSEC как CSECT с именем SAFHFUSR. Если SAFHFUSR CSECT связан с SAFHFSEC, он будет вызван, а запись GSO EXITS будет проигнорирована. Обратите внимание, что все выходы, указанные в записи GSO EXITS, должны быть помещены в LPA. Образец пользовательского мода SMP / E можно найти в CAX1JCL0, член UM80001. Этот пользовательский мод содержит пример выхода вместе с этапами работы по редактированию сборки и ссылки.

При входе на выход регистр R1 указывает на список адресов.Конец списка обозначается старшим битом последнего полного слова.

Для функции инициализации выходу передаются следующие адреса параметров:

  • + 0-Адрес одиночного байта, содержащего символ «I», указывающий, что это функция инициализации.

  • + 4-Адрес 512-байтовой рабочей области для использования программой выхода.

  • + 8-Адрес 255-байтового поля, в котором пользователь может вернуть местоположение пути, в котором расположены пользовательские каталоги.При вводе это поле содержит шестнадцатеричные нули.

  • + 12-Адрес отдельного байта, который, если он установлен в «Y» выходом, указывает, что пользовательское владение файлами действует.

  • + 16-Адрес 256-байтовой таблицы преобразования, которая используется для преобразования определенных специальных символов в имени пути.

Когда программа выхода возвращает местоположение пути к каталогу пользователя, обработка CA SAF HFS использует это имя пути, чтобы определить, следует ли преобразовать имя пути, подлежащее проверке, в такую ​​форму, чтобы идентификатор пользователя владельца пути стал высокоуровневый квалификатор имени пути.Это позволит писать правила для файлов HFS на уровне пользователя и, если они работают в децентрализованной среде, позволит пользователям поддерживать свои собственные правила для файлов HFS. По умолчанию для пользовательских каталогов перевод не выполняется.

Например, если программа выхода возвращает значение / u / в качестве местоположения имени пути к каталогу пользователя, а файл, к которому осуществляется доступ, - это / u / user01 / xfile, то подтвержденное имя ресурса - $$ USER01.XFILE. Правило, разрешающее доступ к этому файлу, может быть:

 

ТИП КЛЮЧА ($$ USER01) (HFS) XFILE UID (*) РАЗРЕШИТЬ

Когда программа выхода возвращает символ «Y», указывающий на то, что пользователь владеет файлами в своем собственном каталоге, проверка не выполняется, если текущий логонид пользователя совпадает с идентификатором пользователя в каталоге пользователя.В предыдущем примере проверка игнорируется, когда USER01 обращается к файлу / u / user01 / xfile. Этот параметр не имеет смысла, если также не возвращается путь к каталогу пользователя.

Поставляемая таблица перевода имеет формат, приемлемый в качестве входных данных для инструкции TR ассемблера. Таблица перевода по умолчанию переводит все символы косой черты в имени пути, за исключением ведущей косой черты, в символ точки. Остальные специальные символы будут переведены в знак доллара ($). К ним относятся символы, которые используются в качестве маскирующих символов в правилах ресурсов.Если не перевести эти символы, это может привести к нежелательным результатам. К специальным символам относятся точка, звездочка, тире, плюс, пробел и кавычки. Выход может дополнительно изменить любой символ в таблице для удовлетворения особых потребностей, за исключением символа косой черты, который всегда будет преобразован в разделитель точки.

Для функции преобразования имени пути выходу передаются следующие адреса параметров:

  • + 0-Адрес одного байта, содержащего символ «P», указывающий, что это функция преобразования имени пути.

  • + 4-Адрес 512-байтовой рабочей области для использования программой выхода.

  • + 8-Адрес 255-байтового поля, содержащего имя ресурса, измененное обработкой CA SAF HFS. Это имя будет использоваться для проверки. Выход может вернуть измененное имя пути в этом же поле.

  • + 12-Адрес 1024-байтового поля, содержащего исходное неизмененное имя пути.

Программа выхода может использовать эту функцию выхода для внесения каких-либо конкретных изменений в имя пути, помимо тех, которые уже были выполнены обработкой безопасности CA SAF HFS.

Хотя доступ к файлу может быть направлен к правилу $$ userid в функции инициализации, а также в функции преобразования имени пути, следует учитывать важное различие. Когда право собственности на файл назначается в функции инициализации, проверка попыток доступа от имени владельца файла не выполняется. Когда вызов преобразования имени пути используется для установки правила $$ userid, владелец файла по-прежнему проходит проверку файла.

Создание отчетов и протоколирование осуществляется через существующий отчет о ресурсах CA ACF2, ACFRPTRV.Когда атрибут TRACE включен в логониде пользователя, записи трассировки также появятся в отчете. В отчете будет отображаться переведенное имя файла HFS, используемого для проверки, вместе с первыми 256 символами исходного имени пути HFS. ACFRPTRV следует рассматривать при исследовании проблем валидации.

Интерфейс безопасности CA SAF HFS можно отследить с помощью команды SECTRACE. Отслеживание внутренних функций безопасности CA SAF HFS активируется с помощью ключевого слова SECTRACE TYPE = HFS.Вывод трассировки может быть запрошен службой технической поддержки. Синтаксис:

 

НАБОР SecTrace, ТИП = HFS

Следующие ключевые слова имеют значение, если указан TYPE = HFS:

 

ID = JOBname = USERid = ВКЛЮЧИТЬ | ВЫКЛЮЧИТЬ ДЕЙСТВИЕ = MATCHLIM = DEST = КОНСОЛЬ | JOBLOG | SYSLOG CONSid = МСГид | НОМСГид

Другие ключевые слова игнорируются. Если DEST не указан, по умолчанию используется DEST = SYSLOG.

Вызовы проверки SAF, инициированные службой безопасности CA SAF HFS, также могут быть отслежены.Эти вызовы SAF представляют собой проверки файлов и функций, которые передаются в CA ACF2. Включите эту трассировку, сначала введя команду SECTRACE SET, описанную ниже, а затем ответьте на приглашение:

 

ST SET, ID = id, TYPE = SAFP, DEST = dest, END R nn, REQSTOR = SAFHFSEC, END

Утилита создания правил CA SAF HFS

Предусмотрено несколько служебных программ для генерации правил ресурсов CA ACF2, которые будут использоваться в качестве начального набора правил для новых реализаций. Правила ресурсов HFS, создаваемые утилитой SAFHFACF, предоставляют доступ на основе битов прав доступа к файлам, определенных для «других» пользователей.Другими словами, правила предоставят пользователям такой же доступ по умолчанию к файлам, какой они имеют, когда не запущена защита CA SAF HFS. Правила ресурсов HFS, создаваемые утилитой SAFHFACL, предоставляют доступ на основе битов прав доступа к файлам, определенных для пользователей в списках контроля доступа (ACL). Сгенерированные правила необходимо просмотреть и изменить, чтобы разрешить соответствующим пользователям доступ к файлам на основе прав владельца и / или группы.

Входной файл служебной программы SAFHFACF создается командой OMVS ls.Этот файл содержит список всех файлов и каталогов в HFS. Входной файл для служебной программы SAFHFACL создается путем обработки выходных данных команды OMVS ls. Выходные файлы обеих утилит содержат команды для компиляции наборов правил CA ACF2 и добавления правил с помощью ACFNRULE. Эти файлы предназначены для просмотра, корректировки и выполнения с использованием пакетного TMP.

Задание ACFHFSRP в библиотеке CAX1JCL0 состоит из нескольких шагов, которые создают необходимые входные файлы и запускают утилиты.Перед выполнением задания ACFHFSRP необходимо предоставить стандартную карточку вакансии и изменить символы на правильные значения для вашего сайта.

  1. Выполните сценарий ACFHFSPP REXX, чтобы создать файлы HFS, которые будут использоваться в качестве входных данных для обеих утилит. Этот исполняемый файл REXX копируется из библиотеки ACF2 CAIEXEC в файловую систему HFS. Он сгенерирует файлы, которые необходимы в качестве входных данных для SAFHFACF и ACFHFACL. Если эти файлы не могут быть созданы, этот шаг возвращает код условия 12.

  2. Выполнить пакетный TMP для копирования файлов HFS в наборы данных MVS.Набор данных HFACFIN должен выглядеть примерно так:

     

    /: всего 232 drwx ------ 3 ОТКРЫТИЕ ПОЛЬЗОВАТЕЛЯMVS 0 3 июня 2001 г. JavaS390 drwxr-xr-x 4 ПОЛЬЗОВАТЕЛЬ 0 7 мая 2001 г. bin drwx - x - x 2 ОТКРЫТИЕ ПОЛЬЗОВАТЕЛЯMVS 0 Oct 1 2000 dev drwxr-xr-x 8 ОТКРЫТИЕ ПОЛЬЗОВАТЕЛЯMVS 0 4 ноя 17:05 и т. д. drwxr-xr-x 2 ПОЛЬЗОВАТЕЛЬ 0 20 января 1998 г. lib drwxrwxrwx 2 ПОЛЬЗОВАТЕЛЬ 0 19 янв, 11:51 tmp drwxr-xr-x 8 ОТКРЫТИЕ ПОЛЬЗОВАТЕЛЯMVS 0 15 янв, 15:47 u drwxr-xr-x 11 ПОЛЬЗОВАТЕЛЬ 0 20 января 2001 г. / JavaS390: всего 16 drwxrwxrwx 7 ПОЛЬЗОВАТЕЛЬ ZEROGRP 0 25 сен 2002 J1.1.1

    Если данные не в этом формате, SAFHFACF прекратит работу.В сообщении об ошибке в файле SYSPRINT будет отображаться строка, которая не была распознана. Файл MVSACLIN должен выглядеть примерно так:
     

    drwxr-xr-x + / u / user1 / dir1 пользователь: 211 rwx -rwx ------ + / u / пользователь1 / файл1 пользователь: 212 r-x пользователь: 213 rw- -rwxrwx --- + / u / пользователь1 / файл2 пользователь: 214 -wx -rw ------- + / u / user1 / file4 пользователь: 215 rw- -rw-r - r - + / u / пользователь1 / файл5 пользователь: 210 r-x пользователь: 211 rwx пользователь: 212 r-x пользователь: 213 r--

    Если в этой файловой системе нет пользовательских ACL, файл MVSACLIN будет содержать сообщение «Никаких ACL не найдено».

  3. Выполните служебную программу SAFHFACF, чтобы сгенерировать команды ACF для создания правил ресурсов на основе «других» битов разрешения. Если для HFS используются имена ресурсов в смешанном регистре, закодируйте карту EXEC следующим образом:

     

    // RUNHFACF EXEC PGRM = SAFHFACF, PARM = MIXED

    PARM = MIXED приведет к созданию правил вывода в смешанном формате. После выполнения задания просмотрите данные в наборах данных RULESETS и RULELINE. Набор данных RULESETS содержит команды для компиляции всех наборов правил, созданных утилитой.Он также содержит команды для резервного копирования существующих правил HFS или FAC путем их декомпиляции в файл. Некоторые наборы правил содержат правила, разрешающие, но регистрирующие доступ в течение 14 дней. Эти правила призваны помочь в процессе внедрения. После просмотра журналов, о которых сообщает ACFRPTRV, и написания соответствующих правил, эти строки правил следует удалить. Набор данных RULELINE содержит команды ACFNRULE для добавления определенных строк правил в наборы правил. Эти данные следует отредактировать, чтобы удалить лишние строки правил.Формат вывода должен делать довольно очевидным, какие строки можно удалить. Например, некоторые записи каталога содержат примеры или демонстрационные файлы, которые можно объединить в одно правило. Рассмотрим следующий вывод утилиты:
     

    КЛЮЧ ACFNRULE (/ USR) ТИП (HFS) NOLIST - ДОБАВИТЬ (LPP.TCPIP.- СЕРВИС (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.CLIENTS.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.CLIENTS.BITMAP.- UID СЕРВИСА (ЧТЕНИЕ) (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.CLIENTS.XAUTH.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.CLIENTS.XCLOCK.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.CLIENTS.XLOGO.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.CLIENTS.XPROP.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.DEMOS.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.DEMOS.XSAMP1.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.DEMOS.XSAMP2.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.MAN.- UID СЕРВИСА (ЧТЕНИЕ) (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.MAN.CAT1.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ)

    Поскольку все каталоги и файлы определены с доступом READ, набор правил можно безопасно сократить до следующего, удалив правила для каталогов в каталоге XAMPLES:

     

    ТИП КЛЮЧА ACFNRULE (/ USR / LPP / TCPIP) (HFS) NOLIST - ДОБАВИТЬ (- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ) - ДОБАВИТЬ (X11R6.XAMPLES.- СЕРВИСНЫЙ (ЧТЕНИЕ) UID (*) РАЗРЕШИТЬ)

    SAFHFACF может выдать сообщение:

     

    Предупреждение - превышена максимальная длина $ PREFIX.

    Это означает, что значение $ PREFIX, созданное для набора правил, превышает максимум 40 символов. Эта проблема может быть решена путем использования маскирования на более низком уровне, чтобы исключить необходимость в наборе правил следующего ключа, или путем сокращения значения $ PREFIX путем удаления уровней имени файла с конца значения $ PREFIX и добавления их в строки правил. самих себя.

  4. Выполните сценарий ACFHFACL REXX, чтобы сгенерировать команды ACF для создания правил ресурсов на основе списков контроля доступа.ACFHFACL требует 1 аргумент: длину строки UID. Строка UID определяется сайтом и может содержать до 24 символов. Укажите правильную длину строки UID для вашего сайта. Этот шаг можно закомментировать, если пользовательские ACL не существуют в этой файловой системе HFS.

После внесения изменений запустите команды, содержащиеся в наборах данных HFSACF.RULELINE, HFSACF.RULESETS и HFSACL.RULELINE, в качестве входных данных для пакетного TMP. Задание ACFHFIKJ в библиотеке CAX1JCL0 можно использовать для выполнения команд CA ACF2, содержащихся в этих наборах данных.Проверьте результат на успешное завершение. Сообщение ACF50035 укажет на любые ошибки во время обработки ACFNRULE. После устранения ошибок вы можете снова запустить измененные команды RULESETS и RULELINE через пакетный TMP. Любые ранее созданные правила будут скопированы с помощью команд в файле RULESETS.

Как упоминалось ранее, созданные правила HFS предоставляют доступ на основе битов прав доступа к файлам, определенных для «других» пользователей. В качестве последнего шага правила должны быть изменены, чтобы предоставить соответствующим пользователям больший доступ к файловым ресурсам, чем предоставлен общему сообществу пользователей.Ключи набора правил должны точно представлять различные приложения, использующие ресурсы HFS. Должны быть определены права собственности и административные обязанности в отношении данных, чтобы правила можно было поддерживать на постоянной основе.

CA SAF HFS Команда изменения безопасности

 

F ACF2, HFS (СОСТОЯНИЕ | ВКЛЮЧИТЬ | ВЫКЛЮЧИТЬ)

Эту консольную команду можно использовать для управления или проверки состояния безопасности CA SAF HFS.

 

F ACF2, HFS (СОСТОЯНИЕ)

Выдает сообщения о текущем состоянии безопасности CA SAF HFS.

 

F ACF2, HFS (ВКЛЮЧИТЬ)

Включает безопасность CA SAF HFS. Если этот параметр включен, обычная проверка защищенного доступа z / OS UNIX не выполняется. Это включает проверку битов прав доступа к файлам, статуса суперпользователя и обычных служб безопасности z / OS UNIX.

 

F ACF2, HFS (ВЫКЛЮЧЕНО)

Отключает безопасность CA SAF HFS. Если этот параметр отключен, включена обычная проверка безопасного доступа z / OS UNIX. Это включает проверку битов прав доступа к файлам, статуса суперпользователя и обычных служб безопасности z / OS UNIX.

Если запрошенная функция - СОСТОЯНИЕ и пользователь, выдающий команду, определен для системы безопасности как аудитор, дальнейшая авторизация не требуется. В противном случае пользователю, запускающему команду, должен быть разрешен доступ к ресурсу в классе SAF FACILITY. Имя ресурса:

 

BPX.CAHFS.SECURITY.function

Где

функция

может иметь статус СОСТОЯНИЕ, ВКЛЮЧИТЬ или ВЫКЛЮЧИТЬ.

CA SAF Безопасность HFS также можно включить или отключить с помощью записи GSO UNIXOPTS.

Если указан HFSSEC, то безопасность CA SAF HFS будет включена после запуска CA ENF / USS. Запись GSO в UNIXOPTS по умолчанию имеет значение NOHFSSEC.

Утилита изменения безопасности CA SAF HFS

Предоставляется служебная программа, позволяющая авторизованным пользователям отображать состояние и включать или отключать безопасность CA SAF HFS. Утилита запускается в пакетном режиме с запрошенной функцией, переданной в поле PARM оператора JCL EXEC. Пример JCL следующий:

 

// имя работы JOB // имя шага EXEC PGM = SAFHFMOD, PARM = function

Где

функция

может быть одной из следующих:

СТАТУС

Выдает сообщение, показывающее текущий статус безопасности CA SAF HFS.

ВКЛЮЧИТЬ

Включает безопасность CA SAF HFS. Если этот параметр включен, обычная проверка защищенного доступа z / OS UNIX не выполняется. Это включает проверку битов прав доступа к файлам, статуса суперпользователя и обычных служб безопасности z / OS UNIX.

ВЫКЛЮЧИТЬ

Отключает безопасность CA SAF HFS. Если этот параметр отключен, включена обычная проверка безопасного доступа z / OS UNIX. Сюда входит проверка битов прав доступа к файлам, статуса суперпользователя и обычных служб безопасности z / OS UNIX.Программа должна находиться в авторизованной библиотеке APF. Если запрошенная функция - это СОСТОЯНИЕ, а пользователь, выполняющий задание, определен для безопасности как аудитор, дальнейшая авторизация не требуется. В противном случае пользователю, выполняющему задание, должен быть разрешен доступ к ресурсу в классе SAF FACILITY. Имя ресурса:
 

BPX.CAHFS.SECURITY.function

Где

функция

может иметь статус СОСТОЯНИЕ, ВКЛЮЧИТЬ или ВЫКЛЮЧИТЬ.

Принципы проектирования Inferno

Инферно Inferno - это распределенная система, основанная на применении трех основных принципов.
  • Ресурсы как файлы: все ресурсы представлены как файлы в иерархической файловой системе
  • Пространства имен: вид приложения в сети - это единое согласованное пространство имен, которое отображается как иерархическая файловая система, но может представлять физически разделенные (локально или удаленно) ресурсы
  • Стандартный протокол связи: стандартный протокол используется для доступа ко всем ресурсам, как локальным, так и удаленным
Ресурсы как файлы
Все ресурсы Inferno, как локальные, так и удаленные, представлены в виде набора динамических файлов в иерархической файловой системе.Эти файлы используются, среди прочего, для представления устройств хранения, процессов, служб, сетей и сетевых подключений. Приложение может получить доступ к каждому ресурсу, при необходимости манипулируя соответствующими файлами, используя стандартные файловые операции. Преимущества использования файлов в качестве центральной концепции системы:
  • Файловые системы имеют простые и понятные интерфейсы для самых разных операционных систем. Интерфейсы к файлам обычно состоят из небольшого набора четко определенных операций, таких как открытие, чтение и запись.
  • Использование файловых систем сокращает объем кода интерфейса и сохраняет систему Inferno компактной, надежной и легко переносимой.
  • Соглашения об именах файлов хорошо известны, единообразны и легко понимаются
  • Права доступа и разрешения для файлов просты, но могут использоваться для обеспечения нескольких уровней безопасности
Имена файлов и содержимое этих динамических файлов могут быть созданы для каждого запроса и для каждого клиента.Например, файл данных для ресурса датчика может возвращать разные выходные данные в зависимости от времени чтения, или для каждого чтения может возвращаться новая строка данных.

Пространства имен
Второй ключевой принцип Inferno - это вычислимое пространство имен, с помощью которого приложение создает уникальное частное представление ресурсов и служб, к которым оно должно получить доступ. Каждый набор ресурсов представлен в виде иерархии файлов и доступен через стандартные операции доступа к файлам. Различные ресурсы и службы, используемые процессом, объединяются в единую корневую иерархию имен файлов, называемую пространством имен.Ресурсы, доступные в отдельном пространстве имен, могут быть расположены на одном клиенте или на нескольких серверах по всей сети.

Одним из основных преимуществ этой системы пространств имен является то, что приложение может использовать ресурсы полностью прозрачно. После того, как динамические файлы, представленные ресурсом, смонтированы в пространстве имен, видимом для приложения, оно может получить к ним доступ, не зная, является ли ресурс локальным или удаленным.

Например, графический отладчик читает динамические файлы в каталоге / prog для доступа к информации о текущих системных процессах.Однако, если пользователь желает отладить процесс на удаленном компьютере, все, что потребуется, - это импортировать каталог / prog с этого компьютера. Что касается отладчика, он просто читает файлы в / prog как обычно и не знает, откуда они берутся.

Стандартный протокол для доступа к ресурсам
Inferno использует единый протокол, реализованный ядром Inferno и приложениями, для представления ресурсов и доступа к ним. Поскольку все ресурсы, включая сети и сетевые подключения, представлены в виде файлов, требуется только один протокол для связи и предоставления доступа к ресурсам, как локальным, так и удаленным.Этот протокол представляет собой протокол файловой службы с именем 9P (более ранний вариант назывался Styx ). Этот подход обеспечивает естественный способ построения распределенных систем с использованием хорошо известной технологии подключения удаленных файловых систем. Наличие одного стандартного протокола связи также обеспечивает единую точку, на которой можно сосредоточить внимание на безопасности. Inferno предоставляет несколько механизмов для безопасной связи:

  • Аутентификация пользователя на основе сертификата
  • Шифрование сообщений
Поскольку это часть базовой системы, все приложения автоматически получают эти преимущества.9P работает по различным транспортным протоколам, включая TCP / IP.

Изначально 9P был разработан для использования с Plan 9 от Bell Labs . Упрощенное подмножество под названием Styx использовалось в Inferno несколько лет, но теперь протокол Inferno точно такой же, как у 9P. Некоторые страницы руководства и старые документы по-прежнему ссылаются на Styx .

модель иерархии Фустера

Напомним, что центральный момент, продемонстрированный моделью BP04, заключается в том, что, несмотря на очевидную иерархическую структуру повседневного последовательного поведения, представления, лежащие в основе такого поведения, не обязательно должны быть, и действительно, вряд ли будут такими. строго иерархический.Вместо этого, как и сама подробная структура повседневного поведения, эти представления, скорее всего, будут квазииерархическими, отражая различия между отдельными уровнями последовательной структуры, а также позволяя обмениваться информацией между этими уровнями и между взаимосвязанными последовательностями задач. Объединив как вычислительные наблюдения, так и эмпирические данные в поддержку этого предположения, мы теперь обратимся к набору результатов, которые, на первый взгляд, могут ему противоречить.

(a) Иерархия Фустера

Опираясь на нейроанатомические данные, Фустер (1990, 1997, 2001, 2004) охарактеризовал систему картографирования корковых областей от перцептивных входов до моторных выходов как формирующую лестничную структуру с первичными сенсорными и сенсорными сигналами. моторная кора у ее основания и префронтальная кора (ПФК) на ее вершине ().

Согласно Фустеру, эта структурная иерархия также содержит параллельную функциональную иерархию. В частности, по мере того, как человек поднимается по уровням от периферии к PFC, последовательные уровни играют меньшую роль в кодировании непосредственных перцептивных входов и моторных выходов и большую роль в представлении временного контекста.Согласно объяснению Фустера, ПФС, находясь на одном конце этого континуума, играет функциональную роль, определяемую в значительной степени его вкладом во «временную интеграцию» поведения (Fuster 2004).

В соответствии с предложением Фустера другие исследователи предположили, что разные уровни последовательной структуры представлены на разных уровнях корковой иерархии, достигающей высшей точки в ПФК. Это было предложено, например, Koechlin и др. . (2003) на основе результатов нейровизуализации, и аналогичное мнение было также выдвинуто Кортни (2004).Хотя ПФК часто ассоциируется с нестандартными действиями, также считается, что он играет решающую роль в координации рутинного последовательного поведения (Sirigu и др. . 1995; Fuster 2001; Zalla и др. . 2003) и Графман (1995, 2002) представил отчет о представлении рутинного последовательного поведения, в котором конкретно предлагается, чтобы разные уровни структуры задачи были представлены на разных уровнях неокортикальной иерархии.

Возвращаясь к версии этой теории Фустера, стоит отметить, что в некоторых отношениях она довольно хорошо согласуется с вычислительной структурой, предложенной BP04.В частности, эти двое разделяют основную идею о том, что последовательное поведение возникает из тщательно продуманного цикла восприятие-действие, в котором посредническую роль играют внутренние репрезентации, способные поддерживать информацию о временном контексте или контексте задачи (см., В частности, Fuster 1990, 2004). . Тем не менее, акцент на иерархической структуре в отчетах Фустера и связанных с ним может показаться противоречащим теории BP04. Верно, что модель BP04 была построена явно неиерархическим образом.Однако важно отделить этот выбор реализации, сделанный для простоты и теоретической ясности, от фундаментальных утверждений учетной записи в отношении иерархической структуры. Как было отмечено, это: (i) механизмы, лежащие в основе рутинных последовательных действий, не требуют, , чтобы сама система обработки принимала иерархическую форму, и (ii) представления, лежащие в основе последовательного действия, не связаны друг с другом в строгая иерархическая мода.Таким образом, в принципе, нет причин, по которым основные механизмы, работающие в модели BP04, не работают в системе, отображающей иерархическую структуру, особенно если эта структура присутствует на уровне, намного превышающем уровень отдельных репрезентативных элементов.

Чтобы подтвердить эту точку зрения, мы реализовали модель нейронной сети на основе структуры BP04, но предполагая структуру, основанную на иерархии Фустера, и обучили ее задаче, требующей сохранения информации временного контекста.Результаты этого моделирования не только помогли установить, как модель BP04 может быть согласована с расчетами Фустера и связанных с ним, но также предположили, как описанная Фустером функциональная иерархия - и особая роль PFC в ней - могут возникнуть в процессе обучения.

(b) Моделирование 1: моделирование иерархии Фустера

В этом исследовании моделирования мы построили модель рекуррентной нейронной сети, которая была аналогична модели, предложенной BP04, в том, что она отображала перцепционные входы в выходы действий через периодически подключаемые скрытые блоки. .Однако, в отличие от BP04, модель включала в себя схему связности, напоминающую лестничную структуру, описанную Фустером (1997). В основе лестницы находилась группа, получавшая внешние входные данные, представляющие стимулы окружающей среды, и группа выходных данных, представляющая двигательные команды. К ним были подключены две внутренние группы единиц, занимавшие промежуточное положение. И с ними была связана последняя группа единиц, занимающая вершину иерархии, положение, аналогичное положению PFC в иерархии Фустера.

Как поясняется ниже, эта сеть была обучена задаче, которая требовала как немедленного сопоставления ввода-вывода, так и поддержки контекстной информации с течением времени. Интересный вопрос заключался в том, приведет ли обучение к тому, что разные группы единиц будут выполнять разные вычислительные роли. В частности, был задан вопрос, возьмет ли на себя «префронтальная» группа на вершине иерархии особую роль в представлении контекстной информации.

(i) Методы моделирования

Сетевая архитектура Архитектура модели представлена ​​на диаграмме.Входная группа содержала 13 единиц, выходная группа - 10 единиц, а остальные группы - 15 единиц. Связи между группами были всесторонними и двунаправленными. Каждая из трех внутренних групп также была внутренне связана, опять же по принципу «все для всех». Все блоки в сети также получали входные данные от блока смещения с тонической активацией одного.

Модель рекуррентной нейронной сети, основанная на иерархии Фустера. Воспроизведено с разрешения Elsevier.

Устройства принимают значения активации от нуля до единицы на основе их входных данных.Чистый вклад каждой единицы был рассчитан как

netj (t) = (1 − τ) netj (t − 1) + τ∑iai (t) wij,

(3.1)

, где a i - активация блока i , w ij - вес соединения блока i с блоком j , а постоянная времени τ была установлена ​​равной 0,2. Активация агрегата была основана на логистической функции

aj (t) = 11 + e − netj (t).

(3.2)

Внешние входы для входной группы были смоделированы путем добавления значения единицы или нуля к чистому входу принимающего устройства.

Задача и представления Задача была выбрана для того, чтобы позволить прямую оценку степени, в которой единицы в модели закодированы для непосредственных входов и выходов, по сравнению с временной контекстной информацией. В частности, мы обучили модель задаче «хранить-игнорировать-вспоминать» (SIR), описанной O'Reilly & Munakata (2000, , ).Это включает в себя представление расширенной серии отдельных арабских цифр. Если представленная цифра отображается черным цветом, задача состоит в том, чтобы просто прочитать ее вслух («игнорировать» испытания). Если цифра отображается красным цветом («сохранить» испытания), она не только должна быть прочитана вслух, но и сохранена в памяти до появления - после переменного числа промежуточных цифр - сигнала отзыва в ответ на о котором необходимо сообщить сохраненный номер (испытания «отзыва»). Чтобы смоделировать эту задачу, цифры от нуля до девяти были представлены с использованием отдельных единиц ввода.Три оставшихся блока ввода указывали пробный тип, причем один блок указывал на черную цифру «игнорировать», один - на красную цифру «сохранить», а третий - на сигнал «возврат». Единицы вывода были идентифицированы с помощью словесных ответов от «ноль» до «девять». Последовательности стимулов генерировались случайным образом, за исключением ограничений, которые заключались в том, что каждое испытание по отзыву отделялось от предыдущего испытания с игнорированием от одного до четырех испытаний с игнорированием, а каждое испытание с сохранением отделялось от предыдущего испытания по отзыву от нуля до двух испытаний с игнорированием.

Обучение Каждое испытание длилось 25 временных шагов. В каждом испытании входное значение, равное единице, применялось к входным единицам, представляющим соответствующую цифру и соответствующий сигнал пробного типа, и целевые значения определялись как для входных, так и для выходных единиц (модель была обучена не только для получения правильного ответа, но также для отправки активации на входной уровень в соответствии с текущим входом). Для выходных единиц цели были равны единице для правильной выходной мощности и нулю для всех остальных единиц.Целевые значения для входных единиц были равны единице для правильных числовых единиц и контрольных единиц и нулю в противном случае, за исключением испытаний отзыва, где никакие целевые значения не применялись к числовым единицам. Активации в начале каждого испытания были просто активами, полученными в результате последнего цикла обработки в предыдущем испытании. Перед первым испытанием обучения все активации юнитов были установлены на 0,5.

Веса были инициализированы случайными значениями от -0,6 до 0,6. Затем было проведено обучение с использованием повторяющегося обратного распространения во времени, как подробно описано в Williams & Zipser (1995), с использованием суммы квадратов ошибок в качестве метрики ошибок.Был задан целевой радиус 0,1, что означает, что не было ошибок для активаций в пределах 0,1 от текущего целевого значения. Использовался льготный период из 10 временных шагов, то есть в течение первых двух интервалов после изменения входных данных ошибок не было. Обратное распространение ошибки охватывало интервал от конца каждой попытки отзыва до конца предыдущей попытки отзыва. Параметр скорости обучения был установлен на 0,001.

Точность ответа в каждом испытании оценивалась путем определения того, была ли целевая единица в выходной группе наиболее активной единицей в конце испытания.В начальном моделировании обучение продолжалось до тех пор, пока модель не показала идеальную производительность для серии из 10 последовательных повторных испытаний. Этот критерий обычно достигался примерно через 2 миллиона обучающих испытаний, и эта продолжительность обучения использовалась при тестировании модели.

Тестирование и анализ Наш интерес был не столько в явных характеристиках модели, сколько в представлениях, лежащих в ее основе. В частности, мы хотели оценить степень, в которой каждая группа единиц в модели была задействована в представлении хранимой контекстной информации, а не в представлении непосредственных входов и выходов.С этой целью мы записали активацию каждого модуля во время обработки набора испытаний игнорирования, происходящих между испытаниями кодирования и отзыва. Было протестировано двадцать конкретных последовательностей, включая S (0) → I (1) → I ( x ) * и S ( x ) → I (1) → I (0) * , где S ( ·) Указывает пробную версию магазина, I (·) пробу игнорирования, x находится в диапазоне от 0 до 9, а звездочка указывает пробную версию, в которой были зарегистрированы активации модулей. Скрытые активации юнитов регистрировались на последнем временном шаге соответствующего шага.Основываясь на полученных активациях, мы оценили степень, в которой активность каждого юнита варьировалась в зависимости от: (i) идентичности текущей `` игнорируемой '' цифры и (ii) идентичности более ранней `` магазинной '' цифры, измеряя ее стандартную отклонение по соответствующему подмножеству испытаний (S (0) → I (1) → I ( x ) * для первого случая, S ( x ) → I (1) → I (0) *) для последнего). Оба стандартных отклонения были усреднены по единицам в каждой группе единиц, а среднее значение для второго набора стандартных отклонений было разделено на среднее значение для первого набора.Результирующая мера, которую мы называем коэффициентом кодирования , обеспечивала индекс степени участия единиц в хранении контекстной информации. Коэффициент кодирования был рассчитан для каждой группы единиц по 10 тренировочным запускам. Чем выше коэффициент кодирования, тем сильнее единицы в соответствующей группе закодированы для контекстной информации (т. Е. Идентичности сохраненных элементов) по сравнению с информацией о непосредственных сопоставлениях ввода-вывода.

(ii) Результаты

Как показано на рисунке, коэффициент кодирования довольно широко варьируется в разных группах, постепенно увеличиваясь с каждым шагом вверх в архитектурной иерархии.Наибольший коэффициент кодирования наблюдался в группе единиц на вершине иерархии. Таким образом, модель, разработанная путем изучения региональной дифференциации функций, подобная той, что описана Фустером (1990, 1997, 2001, 2004), со структурами обработки на более высоких уровнях иерархии - и, в частности, на ее вершине - кодирование предпочтительно для временного контекста Информация. Это разделение труда проявилось и в поведении модели. Когда были поражены единицы в апикальной группе (т.е. инактивировано) производительность модели резко изменилась. Хотя выходные данные оставались правильными при хранении и игнорировали испытания, точность отклика при повторных испытаниях упала до случайного уровня. Поражение группы верхушки также оказало драматическое влияние на коэффициент кодирования для групп ниже по иерархии. Как показано на фиг.2, коэффициенты кодирования во всех остальных группах упали. Это изменение в поведении и внутренних представлениях указывает на то, что группа вершины, аналогичная PFC в иерархии Фустера, играла важную функциональную роль в поддержании информации о временном контексте и передаче ее на более низкие уровни иерархии.

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

(iii) Обсуждение

Центральным моментом, утвержденным с моделью BP04, было то, что иерархически структурированное поведение не требует иерархически структурированной системы обработки и что определенные аспекты действий человека могут быть лучше приспособлены учетной записью, которая не предполагает строгой архитектурной иерархии. . Однако, как мы уже обсуждали, появляется все больше свидетельств взаимосвязи между иерархической организацией коры головного мозга и представлением уровней структуры задач, причем части коры головного мозга, расположенные выше в иерархии, представляют последовательно более высокие уровни структуры задач.Настоящее моделирование показывает, как вычислительная структура, обсуждаемая в BP04, может быть согласована с такими нейробиологическими данными.

Важно отметить, что иерархическая архитектура не требуется для выполнения задачи SIR. Как показали О'Рейли и Мунаката (2000, b ), неиерархическая рекуррентная сеть, почти идентичная по форме модели BP04, может научиться выполнять задачу без ошибок. Однако мы показали здесь, что при наличии иерархической структуры возникает градуированное разделение труда, в соответствии с которым группы единиц, расположенные выше в иерархии, берут на себя непропорционально большую роль в поддержании информации о временном контексте.Результирующий механизм отличается от предложенного в строгих иерархических моделях последовательного действия, поскольку контекстная информация в той или иной степени представлена ​​на всех уровнях иерархии. Вместо этого, несмотря на наличие иерархической структуры, функционирование сети более тесно связано с моделью BP04. Действительно, рассматриваемые как группа, три верхних уровня данной модели выполняют в точности ту же функцию, что и скрытый слой в модели BP04.

Возможно, более важным, чем то, что модель показывает о взаимосвязи между моделью BP04 и иерархическими отчетами, является то, что она предлагает о происхождении региональной специализации в коре головного мозга.В частности, сеть предполагает возможную причинную связь между корковыми связями и региональным разделением труда, которое, как все чаще считается, поддерживает иерархически структурированное поведение. В этой связи важно подчеркнуть, что разделение труда, проиллюстрированное в, возникло довольно спонтанно в результате обучения. В конструкции модели не было ничего, что препятствовало бы обработке контекстной информации полностью на более низких уровнях иерархии. Появление разделения труда в модели, по-видимому, отражает различное давление на группы единиц во время обучения в зависимости от их синаптического расстояния от периферии.Группы, напрямую подключенные к входному и выходному слоям, непосредственно отвечают за создание правильного паттерна активации в этих слоях и, таким образом, находятся под давлением, чтобы четко представлять текущие входы и выходы. При непосредственном отображении ввода-вывода, обрабатываемом группами более низкого уровня, группы, расположенные дальше от периферии, освобождаются для представления контекстной информации. Действительно, имеет смысл представлять такую ​​информацию вдали от периферии, поскольку в задаче есть много шагов, во время которых контекстная информация не имеет отношения к выбору ответа.

Несмотря на свою простоту, это моделирование показывает интересную возможность, касающуюся взаимосвязи между функцией PFC и его связью с другими частями мозга. Фустер (1997) подчеркнул, с одной стороны, участие ПФК в представлении временного контекста, а с другой - положение ПФК на вершине иерархии корковых областей. Наше моделирование дает мотивацию для гипотезы о том, что эти два аспекта PFC причинно связаны: возможность соединения PFC сама по себе может частично объяснить, почему эта область мозга начинает играть роль в представлении временного контекста.

Безусловно, есть и другие отличительные характеристики PFC, которые могут способствовать принятию на себя этой функциональной роли. В частности, было предложено, чтобы PFC обладал свойствами ионного канала, повторяющейся связностью и нейромодулирующей средой, наделяющей его особой способностью хранить информацию с течением времени и в условиях отвлечения внимания (Lisman и др. .1998; O'Reilly и др. .1999; Дюрстевиц и др..2000; О'Рейли и Франк 2006).Настоящее моделирование представляет другое возможное объяснение особой роли PFC в представлении контекста и временной интеграции, не исключающее друг друга с учетом этих других факторов.

Учитывая важную роль, которую обучение играет в нашей теории, необходимо задаться вопросом, в какой степени конкретный вид обучения, включенный в наши симуляции, может соответствовать обучению в мозгу. В частности, использование нами обратного распространения вызывает проблемы, поскольку некоторые аспекты этого алгоритма обучения еще не связаны с известными биологическими механизмами.Важно отметить, что предыдущие исследования (например, Zipser & Anderson 1988) продемонстрировали, что обратное распространение может вызывать паттерны активности, очень похожие на те, которые наблюдаются в реальных нейронных системах. Действительно, это неоднократно было показано в исследованиях, посвященных префронтальной функции (Zipser 1991; Zipser et al .1993; Moody et al .1998). Более того, существуют биологически правдоподобные алгоритмы обучения, работающие аналогично обратному распространению и дающие сопоставимые результаты (Xiaohui & Seung 2003).Тем не менее, обратное распространение во времени, по сути, является единственным доступным в настоящее время алгоритмом обучения нейронной сети, который способен устойчиво обучаться для сохранения контекстной информации с течением времени, и именно это соображение потребовало использования обратного распространения в настоящей работе. Вопрос о том, как эта проблема решается в мозгу, является темой активных исследований (O'Reilly & Frank 2006; Hazy и др. , 2006), и по мере того, как получатся ответы, будет интересно исследовать, дают ли соответствующие алгоритмы поднимаются к той же взаимосвязи между иерархической связностью и функциональной специализацией, которая возникла в нынешних симуляциях.

В этом отношении интерес представляют сходящиеся результаты, недавно опубликованные Paine & Tani (2005). В этой работе использовался генетический алгоритм для обучения иерархически структурированной нейронной сети задаче, требующей сохранения контекстной информации. В соответствии с выводами, которые мы получили с использованием обратного распространения, Paine & Tani (2005) обнаружили, что набор весов связей, который развивался в их моделировании, привел к разделению труда между уровнями сети, причем более высокие уровни играли более центральную роль. роль в представлении контекста.Близкое сходство между результатами, полученными Paine & Tani (2005) с использованием генетического алгоритма, и нашими собственными результатами с использованием прямого градиентного спуска обучения, предполагает, что эффект интереса не зависит от идиосинкразических свойств какого-либо конкретного режима тренировки. но вместо этого может показывать значительную общность.

(c) Моделирование 2: применение к натуралистическим действиям

Для ясности, моделирование 1 обращалось к относительно простой лабораторной задаче, а не к той разновидности последовательностей натуралистических действий, которые рассматривались в BP04.Чтобы показать, как результаты моделирования 1 могут быть переведены в последний контекст, мы выполнили второе моделирование, исследуя влияние включения минимальной архитектурной иерархии в модель BP04. Процедура в большинстве случаев идентична описанной в Botvinick & Plaut (2004). Единственное изменение заключалось в том, что к исходной модели BP04 была добавлена ​​дополнительная группа агрегатов, как показано в и . Эта группа соединялась только с исходным скрытым слоем и, таким образом, находилась на большем синаптическом расстоянии от периферии (входной и выходной слои), чем последний.Как и в симуляции 1, вопрос заключался в том, будут ли единицы, находящиеся дальше от периферии, то есть находящиеся в этом новом слое, играть особую роль в представлении контекста задачи. Чтобы оценить это, модель была обучена задачам, связанным с кофе и чаем, в соответствии с процедурой, использованной в BP04. Затем измеряли активацию единиц в каждом скрытом слое во время выполнения подзадачи упаковки сахара. Чувствительность к немедленным сопоставлениям ввода-вывода измерялась с точки зрения изменения паттерна активации каждого скрытого слоя с последовательными шагами в подзадаче ( b , вверху).Чувствительность к контексту задачи измерялась с точки зрения степени, в которой паттерн активации на каждом этапе подзадачи различается в зависимости от контекста задачи (кофе или чай; b , внизу). Как и в симуляции 1, было обнаружено, что наиболее удаленная от периферии группа модулей предпочтительно кодирует контекстную информацию.

( a ) Повторная реализация модели Botvinick & Plaut (2004) с новым скрытым слоем. Каждый скрытый слой содержал 25 единиц. ( b ) Декартовы расстояния между парами внутренних представлений.

Параллельный иерархический адаптивный многоуровневый проект (PHAML)

Логотип PHAML основан на волновой функции решения задачи на собственные значения, которая моделирует взаимодействие двух атомов, заключенных в оптическую ловушку.

Основные достижения и особенности PHAML:

  • Конечные элементы низкого и высокого порядка на треугольной сетке
  • новый подход к параллельному распределению данных (полный раздел домена)
  • h- , p- и hp - адаптивное уточнение сетки на основе новейшего узла деления пополам
  • множественный выбор для апостериорных индикаторов / оценок ошибок
  • несколько вариантов для hp - адаптивные стратегии
  • параллельный многосеточный решатель на основе иерархических базисных функций h и p
  • дополнительных перехватчиков в популярные пакеты решателей линейных систем (PETSc, hypre, SuperLU, MUMPS) в качестве альтернативы встроенному многосеточному решателю
  • метод разделения на основе дерева уточнения для динамической балансировки нагрузки
  • дополнительные перехватчики в популярные пакеты разметки (Zoltan, ParMETIS) в качестве альтернативы встроенному разделителю
  • Решение скалярных, линейных, самосопряженных, 2D, эллиптических уравнений в частных производных
  • решение других классов УЧП, включая системы уравнений (a.к.а. многокомпонентные решения), задачи на собственные значения (с использованием SLEPc, ARPACK, BLOPEX) и, с внешним циклом, параболические и нелинейные задачи.
  • граничные условия: Дирихле, естественные (обычно Неймана), смешанные и периодические
  • произвольные 2D связанные, ограниченные области, включая изогнутые границы и отверстия
  • использование функций Fortran 90, таких как модули для абстракции данных и необязательные аргументы для упрощения вызовов процедур PHAML
  • сообщение передает параллелизм через MPI
  • Распараллеливание с общей памятью
  • через OpenMP
  • гибридный параллелизм MPI / OpenMP для кластеров многоядерных компьютеров
  • расширенные возможности визуализации с использованием OpenGL для переносимости

Благодаря широкому диапазону функций и возможностей выбора, PHAML может (и использовался) для многих целей, включая:

  • Решатель эллиптических уравнений в частных производных для научных и инженерных приложений
  • Разработка новых численных методов и подходов к программированию параллельных ЭВМ
  • сравнительных исследований различных методов (решатели линейных систем, алгоритмы разбиения, адаптивные стратегии и т. Д.))
  • учебный инструмент для занятий по численным методам или параллельным вычислениям

Каждая панель показывает сетку на одном процессоре. Цвета указывают, какой процессор является «владельцем» треугольников. Слева направо цвета процессора: зеленый, голубой, пурпурный и красный. Сетки разделены по уровням детализации, чтобы показать многосеточную последовательность.

Методы

Исследования, выполненные в рамках проекта PHAML, привели к нескольким достижениям в численных методах решения уравнений в частных производных на параллельных компьютерах.Более подробную информацию можно найти, щелкнув ссылку по каждой теме.

Решение PHAML на четырех процессорах уравнения с сингулярным граничным условием. Цвета или оттенки серого указывают область, назначенную каждому процессору.

Программное обеспечение


Методы, разработанные в рамках проекта PHAML, реализованы в исследовательском коде PHAML. PHAML написан на Fortran 90 и использует MPI для передачи сообщений и OpenMP для параллелизма с общей памятью.Более подробную информацию можно найти, щелкнув ссылку по каждой теме.

Две визуализации 8-процессорного разделения сетки, адаптированной к круговому волновому фронту.

Скачать


PHAML версии 1.20.0 можно загрузить как файл phaml-1.20.0.tar.gz (10,8 МБ) для систем Unix и MS Windows с Cygwin. После распаковки он поместит все в каталог с именем phaml-1.20.0.

Руководство пользователя находится в формате pdf.файл в дистрибутиве, или его можно получить здесь в виде файла pdf (3,9 МБ). Также имеется двухстраничное руководство по быстрому запуску.

PHAML может дополнительно использовать PETSc для альтернативных решателей линейных систем и использовать SLEPc для задач на собственные значения. К сожалению, в прошлом PETSc часто вносил изменения в API, которые требовали изменений в PHAML. Поскольку PHAML больше не находится в разработке, возможно, что версия PETSc, выпущенная после окончательного выпуска PHAML, не будет работать с PHAML. Если вы обнаружите, что это так, вы можете получить последнюю версию PETSc, которая, как известно, работает с PHAML, здесь.Если вы получаете PETSc отсюда, вы также должны получить отсюда SLEPc (если вы используете SLEPc), потому что версия SLEPc должна согласовываться с версией PETSc.

petsc-lite-3.9.3.tar.gz (11,6 МБ)

slepc-3.9.2.tar.gz (4,5 МБ)

Отправляйте вопросы, отчеты об ошибках и т. Д. На phaml [at] nist.gov (тема: вопрос% 20from% 20Drupal% 20PHAML% 20page.).

PHAML находится в общественном достоянии и не подлежит авторскому праву. См. Файл ЛИЦЕНЗИИ.

Решение рассчитано на восьми процессорах.

ИЗДАНИЯ

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

Mitchell, W.F., PHAML User's Guide , NISTIR 7374 , 2006. (оригинал, pdf, 3,2M) (последняя редакция, pdf)

Mitchell, W.F. и Макклейн, M.A., Сравнение адаптивных стратегий для эллиптических уравнений с частными производными hp , Транзакции ACM в математическом программном обеспечении , 41 (1), 2014.(препринт, pdf, 792К) (ссылка на журнал)

Mitchell, W.F. and McClain, M.A., . Сравнение hp - Адаптивные стратегии для эллиптических уравнений с частными производными (длинная версия), NISTIR 7824 , 2011. (pdf, 33M, 215 страниц)

Mitchell, W.F., Сборник двумерных эллиптических задач для тестирования адаптивных алгоритмов , NISTIR 7668 , 2010. (pdf, 1,6M)

Mitchell, W.F. and McClain, M.A., Обзор hp - Адаптивные стратегии для эллиптических уравнений с частными производными, в Последние достижения в вычислительной и прикладной математике (T.Э. Симос, ред.), Springer, 2011, стр. 227-258. (препринт, pdf, 16M)

Mitchell, W.F., Метод разделения на основе дерева уточнения для динамической балансировки нагрузки с адаптивно уточненными сетками , J. Par. Расст. Comp., 67 (4), 2007, стр. 417-429. (pdf, 2.5M) (ссылка на журнал)

Митчелл, В.Ф., Гамильтоновы пути через двумерные и трехмерные сетки , NIST J. Res. , 110, (2005), стр. 127-136. (постскриптум, сжатый gzip, 79 КБ)

Митчелл, В.F., Параллельные адаптивные многоуровневые методы с полными разделами домена , Прил. Num. Анальный. и комп. Математика. , 1, (2004), стр. 36-48. (постскриптум, сжатый gzip, 286k)

Митчелл, В.Ф., Дизайн параллельного адаптивного многоуровневого кода на Фортране 90 , Труды Международной конференции по вычислительным наукам 2002 г. , 2002. (приписка в сжатом виде, 50 КБ)

Mitchell, W.F., Adaptive Grid Refinement and Multigrid on Cluster Computers , Proceedings of the 15th International Parallel and Distributed Processing Symposium , IEEE Computer Society Press, 2001.(запись в формате gzip, 200 КБ)

Mitchell, W.F., A Comparison of Three Fast Repartition Methods for Adaptive Grids , Proceedings of the IX Conference on Parallel Processing for Scientific Computing , 1999. (gzip postscript, 50k)

Mitchell, W.F., Параллельный многосеточный метод с использованием полного раздела домена , Электронные транзакции по численному анализу , 6 (1998) стр. 224-233, специальный выпуск для трудов 8-й конференции Copper Mountain по многосеточным методам.(запись в формате gzip, 100 КБ)

Митчелл, В.Ф., Подход с разделением полной области к параллельному адаптивному уточнению , Объемы IMA по математике и ее приложениям , 113, Springer-Verlag, 1998, стр. 151-162. Том, посвященный семинару IMA по созданию сетей и адаптивным алгоритмам. (запись в сжатом виде, 138 КБ)

Mitchell, W.F., Разбиение дерева уточнения для параллельного решения уравнений с частными производными , NIST Journal of Research , 103 (1998), стр.405-414. (запись в формате gzip, 96k)

Митчелл, У.Ф., Подход с разделением полной области к распределению адаптивных гридов , Прикладная вычислительная математика , 26 (1998) стр. 265-275, специальный выпуск сборников по адаптации гридов в вычислительных УЧП: теория и приложения. (запись в формате gzip, 102k)

Митчелл, В.Ф., Подход с разделением полной области для параллельной многосеточной сети на адаптивных сетках , Труды восьмой конференции SIAM по параллельной обработке для научных вычислений , 1997.(постскриптум, сжатый gzip, 179k)

Митчелл, В.Ф., Разбиение на основе дерева уточнения для адаптивных гридов , Труды 7-й конференции SIAM по параллельной обработке для научных вычислений , SIAM, 1995, стр. 587-592. (постскриптум, сжатый gzip, 75k)

Mitchell, W.F., Оптимальные многоуровневые итерационные методы для адаптивных сеток , SIAM J. Sci. Статист. Comput. 13 (1992), стр. 146–167.

Mitchell, W.F., Адаптивное уточнение для произвольных пространств конечных элементов с иерархическими базами , J.Комп. Прил. Математика. 36 (1991), стр. 65-78.

Mitchell, W.F., Сравнение методов адаптивного уточнения для эллиптических задач , ACM Trans. Математика. Мягкий. 15 (1989), стр. 326-347.

Mitchell, W.F., Единые многоуровневые адаптивные методы конечных элементов для эллиптических задач , Ph.D. дипломная работа, Технический отчет UIUCDCS-R-88-1436, Департамент компьютерных наук, Университет Иллинойса, Урбана, штат Иллинойс, 1988 г. (приписка в сжатом виде, 194 КБ)

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *