Re: Bluetooth модем: wvd ial проблемы
Dmitry E. Oboukhov -> sergio @ Mon, 22 Jun 2015 17:38:42 +0300: >>> но это все жрет слишком много батарейки на мобильнике и в итоге >>> мобильник разряжается быстрее чем ноутбук если сядешь где-то в >>> кафешке. >> А почему не через usb, когда телефон выглядит как usb nic? DEO> дык через USB надо таскать за собой шнурок USB. Эээ... Уж если ты таскаешь и ноут, и телефон, чего б к ноуту в чехол шнурок не кинуть? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87twtzwedh@silver.lasgalen.net
Re: tar incremental archive
tarasca -> debian-russian@lists.debian.org @ Mon, 22 Jun 2015 14:23:21 +0300: t> 1. Из каталога "А" cоздаю полный архив А0.tar и снапшот А.snap (который t> задаётся --list-incremental). Добавляю в каталог "А" файл, создаю (здесь и t> далее используя _копию_ снапшота) инкрементальный А1.tar. Далее в процессе t> работы А1.tar периодически пересоздаётся, А0.tar не трогается (предположим, он t> очень большой, лежит далеко в сети, а изменения даже в сумме весьма мелки по t> сравнению с полным архивом). В дополнение к предыдущим ответам. Если A1.tar периодически пересоздается, то это не инкрементальный, а дифференциальный бэкап. Инкрементальный - это тот, в который попадают изменения по сравнению с предыдущим инкрементальным, поэтому _пере_создавать его - это стрелять себе в ногу. Дифференциальный - тот, в который попадают изменения по сравнению с полным. Я не помню, одинаково они создаются (только относительно разных снапшотов) или по-разному, но лучше эти схемы не путать, во всяком случае при вопросах к сообществу. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4jbweh3@silver.lasgalen.net
Re: tar incremental archive
On Mon, Jun 22, 2015 at 02:23:21PM +0300, tarasca wrote: > Доброго времени. > При изучении tar возникло пару вопросов по инкрементальным архивам, > буду весьма признателен за подсказки. > > 1. Из каталога "А" cоздаю полный архив А0.tar и снапшот А.snap > (который задаётся --list-incremental). Добавляю в каталог "А" файл, > создаю (здесь и далее используя _копию_ снапшота) инкрементальный > А1.tar. Далее в процессе работы А1.tar периодически пересоздаётся, > А0.tar не трогается (предположим, он очень большой, лежит далеко в > сети, а изменения даже в сумме весьма мелки по сравнению с полным > архивом). > Удаляю каталог "А", восстанавливаю из А0.tar и А1.tar. > Пытаюсь сделать инкрементальный архив восстановленного каталога > (фактически сравниваю "А" с состоянием на момент создания А0.tar, > ожидая получить A1.tar), но он совпадает с полным, очевидно дело в > каких-то технических данных (номера/атрибуты инодов?) снапшота, У каталогов изменились inode numbers. Алгоритм прост до безобразия насколько я понимаю. У нас есть список каталогов и их inode numbers. У обычных файлов смотрим на ctime: если он новее, чем дата создания предыдущего архива файл менялся после того - его бэкапим. У каталогов проверяем соответствие имя - inode number, сравнивая с файлом снапшота. Если изменилось - бэкапим все в каталоге с подкаталогами > которые не совпадают с таковыми у восстановленого каталога. > Чтобы не закачивать наново А0.tar я собираюсь ставить костыль: > создать новый снапшот после восстановления из А0.tar (прогоняю > обычную архивацию в /dev/null) и из его копий в дальнейшем лепить > инкременты A1.tar. Можно ли сделать лучше/правильнее? > 2. Ну и общесистемное: чем неприятным грозят инкрементальные бэкакпы > средствами tar, если за пределы наитивных ФС я выходить не планирую? --listed-incremental=SNAPSHOTFILE и --level=N читайте в info tar. Работает сие естественно на posix-совместимых ФС. На ntfs например работает вряд ли. Нужны статические номера inode и posix-овое поведение ctime. Это если про gnu tar. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150622211027.ga12...@intex.spb.ru
Re: Bluetooth модем: wvdial проблемы
>> что сделал. >> >> 1. спарил ноут и телефон по блютух >> 2. sdptool browse видит телефон >> 3. настроил wvdial > По п.3 -- на какое устройство? Нужно же сделать канал типа stream > с помощью rfcomm, иначе непонятно с кем будет общаться wvdial... а, да, я его сделал конечно, просто забыл это описать. между 2 и 3 конечно стоит rfcomm bind device-id channel-no >> вопросы: >> >> 1. если wvdial от первого ATZ перешла ко второму ATQ0, означает ли что >> на ATZ она получила ответ от модема или нет? > Нет, это означает лишь что данные от программы ушли в ядро. Не факт что > дошли до железки. Нужно попросить у wvdial расширенный лог, где видно > что отвечает (и отвечает ли) модем. вопрос в том как попросить у него расширенный лог. в мане wvdial я вижу только три опции, -c, -C и -n >> 3. кто использует телефон в качестве BT-модема, оно батарейки экономит >> вообще? стоит ли копать дальше в этом направлении-то? > Передача сигнала по медному проводнику (usb, ether) всяко эффективнее > чем по воздуху. Хотя бы потому, что энергия не излучается в пространство, > а идёт напрямую к приёмнику. Потому нет нужды в большом коэффициенте > усиления приёмника, у которого КПД меньше 100% и потери пропорциональны > усилению. На проводах практически нет помех, поэтому нет и потерь в виде > ретрансмиссий пакетов. К тому же во всех варинтах радио (bt, wifi) есть > шифрование, которое в конечном счёте жрёт дополнительную энергию. про провода все понятно. интересен BT. телефон с гарнитурой на BT музыку воспроизводит где-то день вполне спокойно. то есть BT-передатчик не так уж много и жрет (по сравнению с Wi-Fi) WiFi передатчик жрет очень много (телефона в режиме AP хватает часа на два максимум). ноутбук от батареек работает часов 8-12. если бы телефона хватало бы на столько же - было б идеально конечно :) как-то так -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Bluetooth модем: wvdial проблемы
On Mon, Jun 22, 2015 at 05:09:58PM +0300, Dmitry E. Oboukhov wrote: > что сделал. > > 1. спарил ноут и телефон по блютух > 2. sdptool browse видит телефон > 3. настроил wvdial По п.3 -- на какое устройство? Нужно же сделать канал типа stream с помощью rfcomm, иначе непонятно с кем будет общаться wvdial... > вопросы: > > 1. если wvdial от первого ATZ перешла ко второму ATQ0, означает ли что > на ATZ она получила ответ от модема или нет? Нет, это означает лишь что данные от программы ушли в ядро. Не факт что дошли до железки. Нужно попросить у wvdial расширенный лог, где видно что отвечает (и отвечает ли) модем. > 3. кто использует телефон в качестве BT-модема, оно батарейки экономит > вообще? стоит ли копать дальше в этом направлении-то? Передача сигнала по медному проводнику (usb, ether) всяко эффективнее чем по воздуху. Хотя бы потому, что энергия не излучается в пространство, а идёт напрямую к приёмнику. Потому нет нужды в большом коэффициенте усиления приёмника, у которого КПД меньше 100% и потери пропорциональны усилению. На проводах практически нет помех, поэтому нет и потерь в виде ретрансмиссий пакетов. К тому же во всех варинтах радио (bt, wifi) есть шифрование, которое в конечном счёте жрёт дополнительную энергию. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150622150141.ga22...@sie.protva.ru
Re: Bluetooth модем: wvd ial проблемы
>> но это все жрет слишком много батарейки на мобильнике и в итоге >> мобильник разряжается быстрее чем ноутбук если сядешь где-то в >> кафешке. > А почему не через usb, когда телефон выглядит как usb nic? дык через USB надо таскать за собой шнурок USB. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Bluetooth модем: wvd ial проблемы
On 06/22/2015 05:09 PM, Dmitry E. Oboukhov wrote: > но это все жрет слишком много батарейки на мобильнике и в итоге > мобильник разряжается быстрее чем ноутбук если сядешь где-то в > кафешке. А почему не через usb, когда телефон выглядит как usb nic? -- sergio. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55881c16.4000...@sergio.spb.ru
Bluetooth модем: wvdial проблемы
Для выхода в интернет через мобильник использовал обычно мобильник в режиме WiFi-доступа. но это все жрет слишком много батарейки на мобильнике и в итоге мобильник разряжается быстрее чем ноутбук если сядешь где-то в кафешке. соответственно хочу попробовать мобильник в режиме блютух модема. что сделал. 1. спарил ноут и телефон по блютух 2. sdptool browse видит телефон 3. настроил wvdial но вот взлететь пока не могу --> WvDial: Internet dialer version 1.61 --> Cannot get information for serial port. --> Initializing modem. --> Sending: ATZ --> Sending: ATQ0 --> Re-Sending: ATZ --> Modem not responding. в dmesg при этом вот такая фигня: Bluetooth: TIOCGSERIAL is not supported гуглил по этой ошибке - пока ничего хорошего не нагуглил. вопросы: 1. если wvdial от первого ATZ перешла ко второму ATQ0, означает ли что на ATZ она получила ответ от модема или нет? 2. кто-то разбирался как победить этот TIOCGSERIAL is not supported? 3. кто использует телефон в качестве BT-модема, оно батарейки экономит вообще? стоит ли копать дальше в этом направлении-то? -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: tar incremental archive
В сообщении от [Пн 2015-06-22 14:23 +0300] tarasca пишет: > Доброго времени. > При изучении tar возникло пару вопросов по инкрементальным архивам, буду > весьма признателен за подсказки. > > 1. Из каталога "А" cоздаю полный архив А0.tar и снапшот А.snap (который > задаётся --list-incremental). Добавляю в каталог "А" файл, создаю (здесь и > далее используя _копию_ снапшота) инкрементальный А1.tar. Далее в процессе > работы А1.tar периодически пересоздаётся, А0.tar не трогается (предположим, > он очень большой, лежит далеко в сети, а изменения даже в сумме весьма мелки > по сравнению с полным архивом). > Удаляю каталог "А", восстанавливаю из А0.tar и А1.tar. > Пытаюсь сделать инкрементальный архив восстановленного каталога (фактически > сравниваю "А" с состоянием на момент создания А0.tar, ожидая получить > A1.tar), но он совпадает с полным, очевидно дело в каких-то технических > данных (номера/атрибуты инодов?) снапшота, которые не совпадают с таковыми у > восстановленого каталога. > Чтобы не закачивать наново А0.tar я собираюсь ставить костыль: создать новый > снапшот после восстановления из А0.tar (прогоняю обычную архивацию в > /dev/null) и из его копий в дальнейшем лепить инкременты A1.tar. Можно ли > сделать лучше/правильнее? > 2. Ну и общесистемное: чем неприятным грозят инкрементальные бэкакпы > средствами tar, если за пределы наитивных ФС я выходить не планирую? Если вы сжимать бекапы не планируете, а только удаленно синхронизировать, то rsync и его производные [1] могут помочь. [1] https://wiki.archlinux.org/index.php/Backup_programs_(Русский) -- http://google.com/+РусланКоротаев -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150622140431.GA1453@debian
Re: Static IP от usb модема с mikrotik на debian
Бридж между чем и чем? У микротик нельзя lte интерфейс добавить в бридж (модем sierra mc7710) 22.06.2015 16:03, Eugene V. Samusev пишет: Так нужно просто ppp сессию поднимать на debian. А микротик настроить в бридж и пусть себе среду преобразовывает. Или ppp поднимает не микротик, а сам модем ? Схему в студию :) -- WBR, Andrey N. Prokofiev Phone: +7-812-645-3616 ext. 240 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5588093a.60...@korona-auto.com
Re: Static IP от usb модема с mikrotik на debian
2015-06-16 18:22 GMT+05:00 Korona Auto Ltd.\ Andrey N. Prokofiev < a...@korona-auto.com>: > День добрый. > > Есть mikrotik с usb модемом и статическим IP (via ppp) > Хочется заиметь статический IP на debian минуя nat. В идеале вообще > использовать порт устройства удаленно (в том числе для отправки sms) Какие > варианты стоит рассмотреть? В mikrotik также в разделе system->ports есть > раздел remote access. Подойдет ли это для поставленной задачи? Так нужно просто ppp сессию поднимать на debian. А микротик настроить в бридж и пусть себе среду преобразовывает. Или ppp поднимает не микротик, а сам модем ? Схему в студию :) -- Евгений Самусев.
Re: Static IP от usb модема с mikrotik на debian
Я бы с радостью, но есть нюанс - модем pci-e вставлен в микротик, микротик вставлен в уличную антенну, метраж точка-точка - 70 метров, питание PoE. Какой еще девайс с портом pci-e и с debian на борту влезет в ограниченное по площади пространство? Сейчас на руках уже имеется именно такое железо. 16.06.2015 16:54, Mikhail A Antonov пишет: А что вообще мешает этот модем подключить не к микротику? Зачем вообще там микротик? Что он умеет такого, что не даст тебе debian? -- WBR, Andrey N. Prokofiev Phone: +7-812-645-3616 ext. 240 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558805a1.3090...@korona-auto.com
Re: tar incremental archive
Я для себя выбрал btrfs - там и архивация на лету, и снапшоты. На текущий момент думаю все же перейти на zfs - я ее на freebsd использую уже года 3, проблемы были только один раз и из-за железа - планка памяти умерла и системный пул не монтировался, но пул с данными оказался полностью живым 22 июня 2015 г., 14:23 пользователь tarasca написал: > Доброго времени. > При изучении tar возникло пару вопросов по инкрементальным архивам, буду > весьма признателен за подсказки. > > 1. Из каталога "А" cоздаю полный архив А0.tar и снапшот А.snap (который > задаётся --list-incremental). Добавляю в каталог "А" файл, создаю (здесь и > далее используя _копию_ снапшота) инкрементальный А1.tar. Далее в процессе > работы А1.tar периодически пересоздаётся, А0.tar не трогается (предположим, > он очень большой, лежит далеко в сети, а изменения даже в сумме весьма > мелки по сравнению с полным архивом). > Удаляю каталог "А", восстанавливаю из А0.tar и А1.tar. > Пытаюсь сделать инкрементальный архив восстановленного каталога > (фактически сравниваю "А" с состоянием на момент создания А0.tar, ожидая > получить A1.tar), но он совпадает с полным, очевидно дело в каких-то > технических данных (номера/атрибуты инодов?) снапшота, которые не совпадают > с таковыми у восстановленого каталога. > Чтобы не закачивать наново А0.tar я собираюсь ставить костыль: создать > новый снапшот после восстановления из А0.tar (прогоняю обычную архивацию в > /dev/null) и из его копий в дальнейшем лепить инкременты A1.tar. Можно ли > сделать лучше/правильнее? > 2. Ну и общесистемное: чем неприятным грозят инкрементальные бэкакпы > средствами tar, если за пределы наитивных ФС я выходить не планирую? > > Заранее признателен. > - > Тарас aka L0ki > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/5587f029.9030...@mail.ru > >
tar incremental archive
Доброго времени. При изучении tar возникло пару вопросов по инкрементальным архивам, буду весьма признателен за подсказки. 1. Из каталога "А" cоздаю полный архив А0.tar и снапшот А.snap (который задаётся --list-incremental). Добавляю в каталог "А" файл, создаю (здесь и далее используя _копию_ снапшота) инкрементальный А1.tar. Далее в процессе работы А1.tar периодически пересоздаётся, А0.tar не трогается (предположим, он очень большой, лежит далеко в сети, а изменения даже в сумме весьма мелки по сравнению с полным архивом). Удаляю каталог "А", восстанавливаю из А0.tar и А1.tar. Пытаюсь сделать инкрементальный архив восстановленного каталога (фактически сравниваю "А" с состоянием на момент создания А0.tar, ожидая получить A1.tar), но он совпадает с полным, очевидно дело в каких-то технических данных (номера/атрибуты инодов?) снапшота, которые не совпадают с таковыми у восстановленого каталога. Чтобы не закачивать наново А0.tar я собираюсь ставить костыль: создать новый снапшот после восстановления из А0.tar (прогоняю обычную архивацию в /dev/null) и из его копий в дальнейшем лепить инкременты A1.tar. Можно ли сделать лучше/правильнее? 2. Ну и общесистемное: чем неприятным грозят инкрементальные бэкакпы средствами tar, если за пределы наитивных ФС я выходить не планирую? Заранее признателен. - Тарас aka L0ki -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5587f029.9030...@mail.ru
