У на IDS 2000 9.21 под Linux'ом.
Пытаюсь записать архив 0-уровня в файл(
т.е. в качестве TAPEDEV использую имя файла
ОС). При достижении файлом размера 2G получаю
сообщение "File size limit exceeded", несмотря на то, что
в Linux'е такого ограничения на размер файла нет.
Мало того, восстановление из архива-0 выполняется
при размере архивного файла более 3G.
Что бы это значило?
С уважением.
Ita.
TI> У на IDS 2000 9.21 под Linux'ом.
TI> Пытаюсь записать архив 0-уровня в файл(
TI> т.е. в качестве TAPEDEV использую имя файла
TI> ОС). При достижении файлом размера 2G получаю
TI> сообщение "File size limit exceeded", несмотря на то, что
TI> в Linux'е такого ограничения на размер файла нет.
TI> Мало того, восстановление из архива-0 выполняется
TI> при размере архивного файла более 3G.
TI> Что бы это значило?
Это значит 2 вещи.
Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
доступ к файлам. Отсюда лимит в 2G.
Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
делать многотомный архив.
--
// yurik shestakov for mail: yu-at-frigate_kiev_ua
Либо писать в fifo. А на другом конце канала можно и сжимать перед
сохранением в файл.
>> TI> в Linux'е такого ограничения на размер файла нет.
>> TI> Мало того, восстановление из архива-0 выполняется
>> TI> при размере архивного файла более 3G.
>> TI> Что бы это значило?
>>
>> Это значит 2 вещи.
>> Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
>> есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
>> доступ к файлам. Отсюда лимит в 2G.
>>
>> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>> делать многотомный архив.
>>
>>
s> Либо писать в fifo. А на другом конце канала можно и сжимать перед
s> сохранением в файл.
У кого такой вариант заработал под Linux ?
В смысле чтобы потом можно было прочитать-восстановить то,
что через pipe получено.
А если на ленту, то проблем нет ?
> TI> т.е. в качестве TAPEDEV использую имя файла
> TI> ОС). При достижении файлом размера 2G получаю
> TI> сообщение "File size limit exceeded", несмотря на то, что
> TI> в Linux'е такого ограничения на размер файла нет.
> TI> Мало того, восстановление из архива-0 выполняется
> TI> при размере архивного файла более 3G.
> TI> Что бы это значило?
>
> Это значит 2 вещи.
> Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
> есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
> доступ к файлам. Отсюда лимит в 2G.
Странно, WinNT тоже 32-битная ОС, тем не менее я могу создавать ontape-ом
файл размером в 8-9G.
> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
> делать многотомный архив.
Для файла на диске, боюсь, не поможет.
--
С уважением,
Василий Шульженко
http://softline.kiev.ua
У меня. IDS 7.30UC10 + kernel 2.4.9-13 + glibc 2.2.4
1. mkfifo /opt/informix/backup.fifo
2. ONCONFIG :
[..]
TAPEDEV /opt/informix/backup.fifo # Tape device path
TAPEBLK 32 # Tape block size (Kbytes)
TAPESIZE 12000000 # Maximum amount of data to put on tape
[..]
3. бэкап :
на одной консоли даешь gzip </opt/informix/backup.fifo > [somefile],
на другой ontape -s
4. востановление :
на одной консоли
for i in 1 2 ; do
gunzip < [somefile] > /opt/informix/backup.fifo
done
на другой ontape -r
И ничего, работает.
>> serge <se...@real.kharkov.ua> wrote:
>> s> yurik shestakov wrote:
>>
>>
>>>> TI> в Linux'е такого ограничения на размер файла нет.
>>>> TI> Мало того, восстановление из архива-0 выполняется
>>>> TI> при размере архивного файла более 3G.
>>>> TI> Что бы это значило?
>>>>
>>>>Это значит 2 вещи.
>>>>Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
>>>>есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
>>>>доступ к файлам. Отсюда лимит в 2G.
>>>>
>>>>Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>>>>делать многотомный архив.
>>>>
>>>>
>>>>
>>
>> s> Либо писать в fifo. А на другом конце канала можно и сжимать перед
>> s> сохранением в файл.
>>
>> У кого такой вариант заработал под Linux ?
>> В смысле чтобы потом можно было прочитать-восстановить то,
>> что через pipe получено.
s> У меня. IDS 7.30UC10 + kernel 2.4.9-13 + glibc 2.2.4
s> 1. mkfifo /opt/informix/backup.fifo
Ага, у меня на 2.2.x ядрах получались битые многотомные архивы.
Надо попробовать по-новой. А то пока "извращаюсь" через файлы,
но работает железно.
s> 2. ONCONFIG :
s> [..]
s> TAPEDEV /opt/informix/backup.fifo # Tape device path
s> TAPEBLK 32 # Tape block size (Kbytes)
s> TAPESIZE 12000000 # Maximum amount of data to put on tape
s> [..]
12G -- не слишком ли "круто" ? ;-)
Хотя должно работать через fifo.
s> 3. бэкап :
s> на одной консоли даешь gzip </opt/informix/backup.fifo > [somefile],
s> на другой ontape -s
s> 4. востановление :
s> на одной консоли
s> for i in 1 2 ; do
s> gunzip < [somefile] > /opt/informix/backup.fifo
s> done
s> на другой ontape -r
s> И ничего, работает.
>>
>> Это значит 2 вещи.
>> Во-первых: в Linux есть 2 группы ф-й для работы с файлами: первая
>> есть 32-битная, вторая -- 64-битная. Informix использует 32-битный
>> доступ к файлам. Отсюда лимит в 2G.
VS> Странно, WinNT тоже 32-битная ОС, тем не менее я могу создавать ontape-ом
VS> файл размером в 8-9G.
Я говорил об двух группах ф-й для работы с файлами: lseek, например.
Реально lseek -- это макрос. Какая ф-я реально вызывается -- зависит
от версии glibc, от наличия/отсутствия определенного __USE_LARGEFILE64
>> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>> делать многотомный архив.
VS> Для файла на диске, боюсь, не поможет.
Что не поможет? У меня размер TAPESIZE=128M
> >> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
> >> делать многотомный архив.
> VS> Для файла на диске, боюсь, не поможет.
> Что не поможет? У меня размер TAPESIZE=128M
Я не учел платформу. Просто на Винде нельзя сделать многотомный архив в файл
:(
Кстати, а зачем тебе такой маленький размер тома ?
>> >> Во-вторых: нужно указать размер TAPEDEV в разумных пределах, и
>> >> делать многотомный архив.
>> VS> Для файла на диске, боюсь, не поможет.
>> Что не поможет? У меня размер TAPESIZE=128M
VS> Я не учел платформу. Просто на Винде нельзя сделать многотомный архив в
VS> файл :(
VS> Кстати, а зачем тебе такой маленький размер тома ?
Меня не смущает 30-40 томов при L0-архиве :)
Хотя лучше -- меньше :)
На предыдущих ядрах нужны были дополнительные пляски с бубном :
1. onconfig :
TAPEBLK 4 # Tape block size (Kbytes)
4 Кб - минимальный поддерживаемый Informix.
2. Пишем небольшую программку на C (впрочем дело вкуса). Назначение -
буферизация потока при чтении:
blockread.c, copyright by Михаил Куринной :
#include <unistd.h>
#include <stdlib.h>
main(int argc, char *argv[]){
int blocksize = atoi(argv[1]);
char *buffer = malloc(blocksize);
while(1){
int bs = blocksize;
while(bs){
int n = read(0, buffer+blocksize-bs, bs);
if (!n) break;
bs -= n;
}
write(1, buffer, blocksize-bs);
if (bs) break;
}
3. компилируем :
gcc blockread.c -o blockread
4. И теперь команда на восстановление :
for i in 1 2 ; do
gunzip < [somefile] | blockread 4096 > /opt/informix/backup.fifo
done
4096 в параметре blockread - количество байт в TAPEBLK из onconfig.
На других размерах размера блока эта технология работать не хотела.
Впрочем дело давнее и я наверняка не помню.
>
> s> 2. ONCONFIG :
>
> s> [..]
> s> TAPEDEV /opt/informix/backup.fifo # Tape device path
> s> TAPEBLK 32 # Tape block size (Kbytes)
> s> TAPESIZE 12000000 # Maximum amount of data to put on tape
> s> [..]
>
> 12G -- не слишком ли "круто" ? ;-)
> Хотя должно работать через fifo.
Да в том то и дело что с fifo связались из-за того что места под
выгрузку на диске не хватало. Вот и пришлось сжимать на лету.