Какие файлы изменяются когда GNU Разделенные уменьшения раздел?

Что изменено, это таблица разделов. Ни один из файлов в разделах не изменяется. Традиционно таблица разделов хранится в MBR (главная загрузка). В качестве альтернативы вы можете иметь GPT (таблица раздела GUID).

Ваш диск обычно структурирован с использованием таблицы раздела , подобных этому:

таблица раздела http://1.1.1.3/bmi/upload.wikimedia.org/wikipedia /commons/thumb/0/07/guid_partition_table_scheme.svg/400px-guid_partition_table_scheme.svg.png

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

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

Детали сокращения файловой системы в значительной степени зависит от типа файловой системы. Есть много очень разных файловых систем с очень разными функциями . (Для некоторых даже не может их сокращаться.)

Добавьте следующую строку под командой rsync в приведенном ниже сценарии оболочки. Я написал это в комментарии, но я официально добавлю его в свой ответ здесь:

    find /auto/std2/nat2/B -name '*.zip' -exec sh -c 'unzip -d `dirname {}` {}' ';'

Это будет обращаться с расстегиванием молнии на всех zip-файлах, которые скопированы через rsync от папки /auto/std2/nat2/A к /auto/std2/nat2/B

, Если вы имеете rsync, установленный, почему не только крон это и имеет , rsync управляет отражающим файлом?

Создают сценарий myrsyncscript.sh

, не забывают делать это выполнимым: chmod 700 myrsyncscript.sh

#!/bin/sh

LOCKFILE=/tmp/.hiddenrsync.lock

if [ -e $LOCKFILE ]
        then
        echo "Lockfile exists, process currently running."
        echo "If no processes exist, remove $LOCKFILE to clear."
        echo "Exiting..."
#        mailx -s "Rsync Lock - Lock File found" myemail@domain.com <<+
#Lockfile exists, process currently running.
#If no processes exist, remove $LOCKFILE to clear.
#+
        exit
fi

touch $LOCKFILE
timestamp=`date +%Y-%m-%d::%H:%M:%s`
echo "Process started at: $timestamp" >> $LOCKFILE

## Run Rsync if no Lockfile
rsync -a --no-compress /auto/std1/nat1/A /auto/std2/nat2/B


echo "Task Finished, removing lock file now at `date +%Y-%m-%d::%H:%M:%s`"
rm $LOCKFILE

Разбивка опций:

-a is for archive, which preserves ownership, permissions etc.
--no-compress as there's no lack of bandwidth between local devices

Дополнительные опции, которые можно рассмотреть man rsync :

--negore-existing

пропускают файлы обновления, существующие в приемнике

--update

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

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

Добавьте его в cron как это, и установите частоту на все, что вы чувствуете наиболее комфортно с:

Откройте cron с crontab -e и добавьте ниже:

### Every 5 minutes
*/5 * * * * /path/to/my/script/myrsyncscript.sh > /path/to/my/logfile 2>&1 

# * * * * *  command to execute
 # │ │ │ │ │
 # │ │ │ │ │
 # │ │ │ │ └───── day of week (0 - 6) (0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the same as 0)
 # │ │ │ └────────── month (1 - 12)
 # │ │ └─────────────── day of month (1 - 31)
 # │ └──────────────────── hour (0 - 23)
 # └───────────────────────── min (0 - 59)

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

Bash-синтаксический анализатор генерируется с помощью yacc (или, как правило, с помощью bison , но в режиме yacc ). синтаксические анализаторы yacc являются синтаксическими анализаторами снизу вверх, используя алгоритм LALR (1), который строит конечный автомат с толкающим стеком. Нечетко говоря, стек содержит все еще не уменьшенные символы, а также достаточно информации, чтобы решить, какие производственный использовать для уменьшения символов.

Такие синтаксические анализаторы оптимизированы для правил леворекурсивной грамматики. В контексте грамматики выражения леворекурсивное правило применяется к левоассоциативному оператору, такому как a − b в обычной математике. Это слева ассоциативно, потому что выражение a − b − c группы («ассоциативные») слева, делая его равным ( a − b )− c, а не a − ( b − c ). Напротив, возведение в степень является правоассоциативным, так что a ^{b c} по соглашению оценивается как a ^{( b c )} , а не ( a ^b ) ^c .

операторы bash являются операторами процессов, а не арифметическими операторами; к ним относятся булевы с коротким замыканием ( и и | | ) и трубы ( | и | и ), а также операторы последовательности ; и и . Как и математические операторы, большинство из них связываются слева, но операторы каналов связываются справа, так что cmd1 | cmd2 | cmd3 анализируется так, как будто это cmd1 | {cmd2 | cmd3;} в отличие от {cmd1 | cmd2;} | cmd3 . (Большую часть времени разница не важна, но она наблюдаема. [См. Примечание 1])

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

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

statement | statement | ... | statement 

в конечном итоге вызовет эту ошибку. Если бы он был проанализирован очевидным образом, это произошло бы после 5000 символов трубы (с 5000 операторов). Но из-за того, как bash синтаксический анализатор обрабатывает новые строки, фактическая используемая грамматика (примерно):

pipeline: command '|' optional_newlines pipeline

, вследствие чего существует необязательный _ newlines грамматический символ после каждого | , так что каждая труба занимает три слота стека. Следовательно, ошибка нехватки памяти генерируется после 3333 символов канала.

Синтаксический анализатор yacc обнаруживает переполнение стека и сигнализирует о нем, вызывая yyerror («память исчерпана») . Однако bash реализация yyerror отбрасывает предоставленное сообщение об ошибке и подставляет сообщение типа «синтаксическая ошибка, обнаруженная вблизи неожиданного маркера».... В данном случае это немного сбивает с толку.

Примечания

1. Разницу в ассоциативности легче всего наблюдать с помощью оператора | & , который направляет stderr и stdout. (Или, точнее,дублирует stdout в stderr после установки трубы.) В качестве простого примера предположим, что файл foo не существует в текущем каталоге. Тогда

    # В этом примере есть условие гонки. Но это не актуально.
   $ ls foo | ls foo | & tr n-za-m a-z
   ls: не может получить доступ к foo: нет такого файла или каталога
   yf: pnaabg npprff sbb: Nb fhpu svyr be qverpgbel
   # Связанные слева:
   $ {ls foo | ls foo;} | & tr n-za-m a-z
   yf: pnaabg npprff sbb: Nb fhpu svyr be qverpgbel
   yf: pnaabg npprff sbb: Nb fhpu svyr be qverpgbel
   # Связано справа:
   $ ls foo | {ls foo | & tr n-za-m a-z;}
   ls: не может получить доступ к foo: нет такого файла или каталога
   yf: pnaabg npprff sbb: Nb fhpu svyr be qverpgbel
   

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

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

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