Re: [Lug-bg] Disk scrubbing

2018-03-04 Thread Peter Pentchev 
On Sun, Mar 04, 2018 at 10:54:45AM +0200, browseman wrote:
> On 02/19/2018 04:36 PM, Marian Marinov wrote:
[snip]
> > Но в момента в който клиента си изтрие container-а ние започваме да 
> > scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да 
> > препълним thinpool-a :(
[snip]
> >
> > Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на 
> > негово място(на неговите blocks) няма нови данни, това означава, че ще 
> > пропусна да scrub-на тези данни.
> 
> Привет
> 
> Аз имам следното доста баламско предложение за решение на казуса, може
> би няма да е приложимо в конкретният случай, но все пак ще споделя идеята:
> 
> - монтира се дяла в произволна директория
> - изпълнява се нещо от сорта "#find /path/to/mounted/thinvol -xdev -type
> f | xargs shred -n1 -z -u", като разбира се ще има проблеми с файлове
> съдържащи интервали или други специални символи в името си, но все
> сравнително лесно решими - IMHO.

Две неща тук:
- проблемите с файловете, съдържащи интервали, са решени в повечето
  реализации на find/xargs, вкл. GNU findutils, с използване на
  `find -print0 | xargs -0`
- find | xargs няма да направи нищо по въпроса с блоковете с данни от
  изтритите файлове

Поздрави,
Петър

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-03-04 Thread browseman 
On 02/19/2018 04:36 PM, Marian Marinov wrote:
> Здравейте група,
> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един казус 
> над който можем да "медитираме" заедно :)
>
>
> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в нашата 
> система, но предвид, че използваме thinpools се получава следният неприятен 
> казус.
> Ако thinpool-а е на 85% и някой си направи много голям volume, докато този 
> volume не е много пълен системата няма проблем.
> Но в момента в който клиента си изтрие container-а ние започваме да 
> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да 
> препълним thinpool-a :(
>
> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни върху 
> един partition/logical volume, само върху секторите в които реално има данни 
> :)
>
> По принцип chunksync & casync прават подобен анализ на volume-а и копират 
> само разликите, но на мен ми трябва вместо разлики да се записват данни, пък 
> било то и нули.
>
> Аз в момента обмислям дали да patch-на dd, да има опция която да му казва да 
> прочете блокчето и ако там няма данни да не записва нищо или да напиша 
> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за които 
> FS-а знае, че има данни.
>
> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на негово 
> място(на неговите blocks) няма нови данни, това означава, че ще пропусна да 
> scrub-на тези данни.
>
>
> Поздрави,
> Мариян
>
>
>
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg

Привет

Аз имам следното доста баламско предложение за решение на казуса, може
би няма да е приложимо в конкретният случай, но все пак ще споделя идеята:

- монтира се дяла в произволна директория
- изпълнява се нещо от сорта "#find /path/to/mounted/thinvol -xdev -type
f | xargs shred -n1 -z -u", като разбира се ще има проблеми с файлове
съдържащи интервали или други специални символи в името си, но все
сравнително лесно решими - IMHO.
- изтриват се всички директории
- демонтира се и в/у дяла се изпълнява mkfs.{FS_TYPE}
/dev/mapper/thinvol (с цел да се затрият и мета-данните от файловата
система) - може и да има по-хитър начин, но поне аз не се досещам.

Потенциален проблем ще има, ако съществува голям sparse, който неминуемо
ще доведе до заемане на повече място от колко реално е използвал.


73.

___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-21 Thread Momchil Ivanov 
On Tue, February 20, 2018 4:33 pm, Momchil Ivanov wrote:
> On Tue, February 20, 2018 3:42 pm, Marian Marinov wrote:
>> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще
>> hit-ва
>> сериозно write performance-а за клиента.
>> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се
>> случва write със същата големина :(
>
> На пръв поглед това даже се случва като си избереш
>
> LV Zero new blocks yes
>
> погледни например [1] и по специално [2]. Предпологам трябва да се
> разгледа по-подробно за да се види дали става навсякъде където трябва.
>
> 1:
> https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1248
> 2:
> https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1310
>
> Поздрави,
> Момчил
>

Хм, това нещо ми показва друг код като го отварям през лаптопа, странна
работа. Става въпрос за следното парче код от drivers/md/dm-thin.c

/*
 * A partial copy also needs to zero the uncopied region.
 */
static void schedule_copy(struct thin_c *tc, dm_block_t virt_block,
  struct dm_dev *origin, dm_block_t data_origin,
  dm_block_t data_dest,
  struct dm_bio_prison_cell *cell, struct bio *bio,
  sector_t len)
{
int r;
struct pool *pool = tc->pool;
struct dm_thin_new_mapping *m = get_next_mapping(pool);

m->tc = tc;
m->virt_begin = virt_block;
m->virt_end = virt_block + 1u;
m->data_block = data_dest;
m->cell = cell;

/*
 * quiesce action + copy action + an extra reference held for the
 * duration of this function (we may need to inc later for a
 * partial zero).
 */
atomic_set(>prepare_actions, 3);

if (!dm_deferred_set_add_work(pool->shared_read_ds, >list))
complete_mapping_preparation(m); /* already quiesced */

/*
 * IO to pool_dev remaps to the pool target's data_dev.
 *
 * If the whole block of data is being overwritten, we can issue the
 * bio immediately. Otherwise we use kcopyd to clone the data first.
 */
if (io_overwrites_block(pool, bio))
remap_and_issue_overwrite(tc, bio, data_dest, m);
else {
struct dm_io_region from, to;

from.bdev = origin->bdev;
from.sector = data_origin * pool->sectors_per_block;
from.count = len;

to.bdev = tc->pool_dev->bdev;
to.sector = data_dest * pool->sectors_per_block;
to.count = len;

r = dm_kcopyd_copy(pool->copier, , 1, ,
   0, copy_complete, m);
if (r < 0) {
DMERR_LIMIT("dm_kcopyd_copy() failed");
copy_complete(1, 1, m);

/*
 * We allow the zero to be issued, to simplify the
 * error path.  Otherwise we'd need to start
 * worrying about decrementing the prepare_actions
 * counter.
 */
}

/*
 * Do we need to zero a tail region?
 */
if (len < pool->sectors_per_block && pool->pf.zero_new_blocks) {
atomic_inc(>prepare_actions);
ll_zero(tc, m,
data_dest * pool->sectors_per_block + len,
(data_dest + 1) * pool->sectors_per_block);
}
}

complete_mapping_preparation(m); /* drop our ref */
}

и съответната документация от lvmthin(7):

Zeroing
When a thin pool provisions a new data block for a thin LV, the new block
is first overwritten with zeros. The zeroing mode is indicated by the "z"
attribute displayed by lvs. The option -Z (or --zero) can be added to
commands to specify the zeroing mode.

Command to set the zeroing mode when creating a thin pool LV:
lvconvert --type thin-pool -Z{y|n}
--poolmetadata VG/ThinMetaLV VG/ThinDataLV
Command to change the zeroing mode of an existing thin pool LV:
lvchange -Z{y|n} VG/ThinPoolLV

If zeroing mode is changed from "n" to "y", previously provisioned blocks
are not zeroed.

Provisioning of large zeroed chunks impacts performance.

lvm.conf(5) thin_pool_zero
controls the default zeroing mode used when creating a thin pool.

___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-21 Thread Marian Marinov 
On 02/20/2018 08:31 PM, Vladimir Vitkov wrote:
> Все още никой не е споменал една деебна особенност на ssd-тата. Именно че не 
> са хддта и че имат FTL и че няма гаранция това което ти казва чипа да е 
> истина. Даже по сигурно е че е лъжа.
> 
> Друго предложение: защо не криптираш дяловете при създаване. Новият ключ дори 
> да е върху същите физически блокове ги прочита като боклук.

Криптирането, предвид, че променя данните, няма ли реално да напълни дяла?
Предполагам визираш LUKS?

> 
> On Feb 20, 2018 16:46, "Marian Marinov"  > wrote:
> 
> On 02/20/2018 01:00 PM, Momchil Ivanov wrote:
> > On Mon, February 19, 2018 3:36 pm, Marian Marinov wrote:
> >> Здравейте група,
> >> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един
> >> казус над който можем да "медитираме" заедно :)
> >>
> >>
> >> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
> >> нашата система, но предвид, че използваме thinpools се получава 
> следният
> >> неприятен казус.
> >> Ако thinpool-а е на 85% и някой си направи много голям volume, докато 
> този
> >> volume не е много пълен системата няма проблем.
> >> Но в момента в който клиента си изтрие container-а ние започваме да
> >> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме 
> да
> >> препълним thinpool-a :(
> >>
> >> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни 
> върху
> >> един partition/logical volume, само върху секторите в които реално има
> >> данни :)
> >>
> >> По принцип chunksync & casync прават подобен анализ на volume-а и 
> копират
> >> само разликите, но на мен ми трябва вместо разлики да се записват 
> данни,
> >> пък било то и нули.
> >>
> >> Аз в момента обмислям дали да patch-на dd, да има опция която да му 
> казва
> >> да прочете блокчето и ако там няма данни да не записва нищо или да 
> напиша
> >> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за
> >> които FS-а знае, че има данни.
> >>
> >> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на
> >> негово място(на неговите blocks) няма нови данни, това означава, че ще
> >> пропусна да scrub-на тези данни.
> >>
> >>
> >> Поздрави,
> >> Мариян
> >
> > Здравей,
> >
> > в случай, че целта ти е друг клиент да не вижда старата информация на 
> този
> > клиент, решението е може би по-просто. Трябва да зануляваш секторите,
> > когато те се зачисляват за първи път от lvm за даден клиент. По този 
> начин
> > дори и той да се пробва да си прочете цялото му заделено място с dd, ще
> > види едно нищо. За целта може би трябва малка добавка в lvm, в случай че
> > няма такава опция.
> >
> > По този начин ще презаписваш само нужните сектори. В края на живота на
> > диска трябва така или иначе да го презапишеш целия, преди да го 
> изхвърлиш.
> 
> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще 
> hit-ва сериозно write performance-а за клиента.
> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се 
> случва write със същата големина :(
> 
> 
> > Поздрави,
> > Момчил
> > ___
> > Lug-bg mailing list
> > Lug-bg@linux-bulgaria.org 
> > http://linux-bulgaria.org/mailman/listinfo/lug-bg 
> 
> >
> 
> 
> 
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org 
> http://linux-bulgaria.org/mailman/listinfo/lug-bg 
> 
> 
> 
> 
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
> 




signature.asc
Description: OpenPGP digital signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Vladimir Vitkov 
Все още никой не е споменал една деебна особенност на ssd-тата. Именно че
не са хддта и че имат FTL и че няма гаранция това което ти казва чипа да е
истина. Даже по сигурно е че е лъжа.

Друго предложение: защо не криптираш дяловете при създаване. Новият ключ
дори да е върху същите физически блокове ги прочита като боклук.

On Feb 20, 2018 16:46, "Marian Marinov"  wrote:

> On 02/20/2018 01:00 PM, Momchil Ivanov wrote:
> > On Mon, February 19, 2018 3:36 pm, Marian Marinov wrote:
> >> Здравейте група,
> >> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един
> >> казус над който можем да "медитираме" заедно :)
> >>
> >>
> >> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
> >> нашата система, но предвид, че използваме thinpools се получава следният
> >> неприятен казус.
> >> Ако thinpool-а е на 85% и някой си направи много голям volume, докато
> този
> >> volume не е много пълен системата няма проблем.
> >> Но в момента в който клиента си изтрие container-а ние започваме да
> >> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да
> >> препълним thinpool-a :(
> >>
> >> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни
> върху
> >> един partition/logical volume, само върху секторите в които реално има
> >> данни :)
> >>
> >> По принцип chunksync & casync прават подобен анализ на volume-а и
> копират
> >> само разликите, но на мен ми трябва вместо разлики да се записват данни,
> >> пък било то и нули.
> >>
> >> Аз в момента обмислям дали да patch-на dd, да има опция която да му
> казва
> >> да прочете блокчето и ако там няма данни да не записва нищо или да
> напиша
> >> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за
> >> които FS-а знае, че има данни.
> >>
> >> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на
> >> негово място(на неговите blocks) няма нови данни, това означава, че ще
> >> пропусна да scrub-на тези данни.
> >>
> >>
> >> Поздрави,
> >> Мариян
> >
> > Здравей,
> >
> > в случай, че целта ти е друг клиент да не вижда старата информация на
> този
> > клиент, решението е може би по-просто. Трябва да зануляваш секторите,
> > когато те се зачисляват за първи път от lvm за даден клиент. По този
> начин
> > дори и той да се пробва да си прочете цялото му заделено място с dd, ще
> > види едно нищо. За целта може би трябва малка добавка в lvm, в случай че
> > няма такава опция.
> >
> > По този начин ще презаписваш само нужните сектори. В края на живота на
> > диска трябва така или иначе да го презапишеш целия, преди да го
> изхвърлиш.
>
> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще hit-ва
> сериозно write performance-а за клиента.
> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се
> случва write със същата големина :(
>
>
> > Поздрави,
> > Момчил
> > ___
> > Lug-bg mailing list
> > Lug-bg@linux-bulgaria.org
> > http://linux-bulgaria.org/mailman/listinfo/lug-bg
> >
>
>
>
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>
>
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Momchil Ivanov 
On Tue, February 20, 2018 4:33 pm, Momchil Ivanov wrote:
> On Tue, February 20, 2018 3:42 pm, Marian Marinov wrote:
>> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще
>> hit-ва
>> сериозно write performance-а за клиента.
>> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се
>> случва write със същата големина :(
>
> На пръв поглед това даже се случва като си избереш
>
> LV Zero new blocks yes
>
> погледни например [1] и по специално [2]. Предпологам трябва да се
> разгледа по-подробно за да се види дали става навсякъде където трябва.
>
> 1:
> https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1248
> 2:
> https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1310

Едно уточнение за производителността: не е нужно да пишеш по два пъти,
понеже самото писане е на практика презаписване и унищожава записаната
преди това информация. На практика пишеш един блок, който при нужда
допълваш с 0 или нещо друго по твое желание, за да не изтечеш от ram върху
диска и за да презапишеш достатъчно парче от диска, което после ще можеш
да прочетеш без да знаеш точно до къде ти стигат данните в него.

Т.е. замазването става в ram паметта преди да отиде като едно цяло в
диска. Последният не се натоварва двукратно. Операциите в паметта са
евтини.

Така че scrub решението ти би било да си включиш опцията за lvm парцелите
и да прегледаш евентуално дали не са изпусвали някъде да нулират при други
операции.

Поздрави,
Момчил
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Momchil Ivanov 
On Tue, February 20, 2018 3:42 pm, Marian Marinov wrote:
> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще hit-ва
> сериозно write performance-а за клиента.
> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се
> случва write със същата големина :(

На пръв поглед това даже се случва като си избереш

LV Zero new blocks yes

погледни например [1] и по специално [2]. Предпологам трябва да се
разгледа по-подробно за да се види дали става навсякъде където трябва.

1: https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1248
2: https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1310

Поздрави,
Момчил
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Ivan Denkov 
Здравейте, тук май не съм писал до сега.

Относно казуса, дали не може да се проверят секторите с badblocks -t, на
теория би трябвало да може да се тестват секторите за определен pattern и
да изкара само тези който са занулени (или не са), а останалите могат да се
подадат на dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=62 като seek и
bs трябва да са еднакви за dd и badblocks. Всичките тези неща съм си ги
изсмукал от пръстите, не съм го правил и даже не съм тествал изхода от
badblcoks дали ще работи, ако не - все трябва да има друга програма която
да провери съдържанието на секторите и да се подаде резултата от нея на dd.

Ще ми е интересно да мина на събирането - много хора ли сте - в смисъл има
ли място обикновенно и проблем ли е ако дойда по средата на срещата?

2018-02-20 16:42 GMT+02:00 Marian Marinov :

> On 02/20/2018 01:00 PM, Momchil Ivanov wrote:
> > On Mon, February 19, 2018 3:36 pm, Marian Marinov wrote:
> >> Здравейте група,
> >> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един
> >> казус над който можем да "медитираме" заедно :)
> >>
> >>
> >> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
> >> нашата система, но предвид, че използваме thinpools се получава следният
> >> неприятен казус.
> >> Ако thinpool-а е на 85% и някой си направи много голям volume, докато
> този
> >> volume не е много пълен системата няма проблем.
> >> Но в момента в който клиента си изтрие container-а ние започваме да
> >> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да
> >> препълним thinpool-a :(
> >>
> >> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни
> върху
> >> един partition/logical volume, само върху секторите в които реално има
> >> данни :)
> >>
> >> По принцип chunksync & casync прават подобен анализ на volume-а и
> копират
> >> само разликите, но на мен ми трябва вместо разлики да се записват данни,
> >> пък било то и нули.
> >>
> >> Аз в момента обмислям дали да patch-на dd, да има опция която да му
> казва
> >> да прочете блокчето и ако там няма данни да не записва нищо или да
> напиша
> >> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за
> >> които FS-а знае, че има данни.
> >>
> >> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на
> >> негово място(на неговите blocks) няма нови данни, това означава, че ще
> >> пропусна да scrub-на тези данни.
> >>
> >>
> >> Поздрави,
> >> Мариян
> >
> > Здравей,
> >
> > в случай, че целта ти е друг клиент да не вижда старата информация на
> този
> > клиент, решението е може би по-просто. Трябва да зануляваш секторите,
> > когато те се зачисляват за първи път от lvm за даден клиент. По този
> начин
> > дори и той да се пробва да си прочете цялото му заделено място с dd, ще
> > види едно нищо. За целта може би трябва малка добавка в lvm, в случай че
> > няма такава опция.
> >
> > По този начин ще презаписваш само нужните сектори. В края на живота на
> > диска трябва така или иначе да го презапишеш целия, преди да го
> изхвърлиш.
>
> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще hit-ва
> сериозно write performance-а за клиента.
> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се
> случва write със същата големина :(
>
>
> > Поздрави,
> > Момчил
> > ___
> > Lug-bg mailing list
> > Lug-bg@linux-bulgaria.org
> > http://linux-bulgaria.org/mailman/listinfo/lug-bg
> >
>
>
>
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>
>
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Marian Marinov 
On 02/20/2018 01:00 PM, Momchil Ivanov wrote:
> On Mon, February 19, 2018 3:36 pm, Marian Marinov wrote:
>> Здравейте група,
>> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един
>> казус над който можем да "медитираме" заедно :)
>>
>>
>> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
>> нашата система, но предвид, че използваме thinpools се получава следният
>> неприятен казус.
>> Ако thinpool-а е на 85% и някой си направи много голям volume, докато този
>> volume не е много пълен системата няма проблем.
>> Но в момента в който клиента си изтрие container-а ние започваме да
>> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да
>> препълним thinpool-a :(
>>
>> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни върху
>> един partition/logical volume, само върху секторите в които реално има
>> данни :)
>>
>> По принцип chunksync & casync прават подобен анализ на volume-а и копират
>> само разликите, но на мен ми трябва вместо разлики да се записват данни,
>> пък било то и нули.
>>
>> Аз в момента обмислям дали да patch-на dd, да има опция която да му казва
>> да прочете блокчето и ако там няма данни да не записва нищо или да напиша
>> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за
>> които FS-а знае, че има данни.
>>
>> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на
>> негово място(на неговите blocks) няма нови данни, това означава, че ще
>> пропусна да scrub-на тези данни.
>>
>>
>> Поздрави,
>> Мариян
> 
> Здравей,
> 
> в случай, че целта ти е друг клиент да не вижда старата информация на този
> клиент, решението е може би по-просто. Трябва да зануляваш секторите,
> когато те се зачисляват за първи път от lvm за даден клиент. По този начин
> дори и той да се пробва да си прочете цялото му заделено място с dd, ще
> види едно нищо. За целта може би трябва малка добавка в lvm, в случай че
> няма такава опция.
> 
> По този начин ще презаписваш само нужните сектори. В края на живота на
> диска трябва така или иначе да го презапишеш целия, преди да го изхвърлиш.

Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще hit-ва 
сериозно write performance-а за клиента.
Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се случва 
write със същата големина :(


> Поздрави,
> Момчил
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
> 




signature.asc
Description: OpenPGP digital signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Momchil Ivanov 
On Mon, February 19, 2018 3:36 pm, Marian Marinov wrote:
> Здравейте група,
> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един
> казус над който можем да "медитираме" заедно :)
>
>
> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
> нашата система, но предвид, че използваме thinpools се получава следният
> неприятен казус.
> Ако thinpool-а е на 85% и някой си направи много голям volume, докато този
> volume не е много пълен системата няма проблем.
> Но в момента в който клиента си изтрие container-а ние започваме да
> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да
> препълним thinpool-a :(
>
> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни върху
> един partition/logical volume, само върху секторите в които реално има
> данни :)
>
> По принцип chunksync & casync прават подобен анализ на volume-а и копират
> само разликите, но на мен ми трябва вместо разлики да се записват данни,
> пък било то и нули.
>
> Аз в момента обмислям дали да patch-на dd, да има опция която да му казва
> да прочете блокчето и ако там няма данни да не записва нищо или да напиша
> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за
> които FS-а знае, че има данни.
>
> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на
> негово място(на неговите blocks) няма нови данни, това означава, че ще
> пропусна да scrub-на тези данни.
>
>
> Поздрави,
> Мариян

Здравей,

в случай, че целта ти е друг клиент да не вижда старата информация на този
клиент, решението е може би по-просто. Трябва да зануляваш секторите,
когато те се зачисляват за първи път от lvm за даден клиент. По този начин
дори и той да се пробва да си прочете цялото му заделено място с dd, ще
види едно нищо. За целта може би трябва малка добавка в lvm, в случай че
няма такава опция.

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

Поздрави,
Момчил
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-20 Thread Peter Pentchev 
On Tue, Feb 20, 2018 at 09:44:45AM +0200, Neter wrote:
> Дали си обърнал внимание, че sparse в dd се отнася за input-а, а не за
> output-а, и дали това не е причината да си се спънал с него? Но може и точно
> това отношение да „обърнеш“ (в кавички, защото няма да е точно обръщане),
> като patch-ваш dd, за да сработи за целта.
> 
> Между другото, щом става дума за SSD, да напомня, че ще имаш полза за
> скоростта на изпълнение, ако пуснеш няколко процеса да трият различни части
> от диска, независимо дали с dd, xxd или каквото там решиш да ползваш.

Всъщност ако го правиш върху SSD, всичко *би трябвало* да бъде много
по-просто: би трябвало да можеш (може би с нов инструмент, но
елементарен) да кажеш на LVM "discard на всички сектори на този logical
volume".  Би трябвало в този момент LVM да си погледне таблицата с
allocated space и да каже "ми то 90% от секторите в този logical volume
са unallocated, така че за тях този discard минава веднага, а за
останалите ей-сега ще пратим discard-ове на SSD-то" и това да е всичко.
Май има инструментче blkdiscard, на което да можеш да му кажеш "целия
диск" (със --zeroout, разбира се).  Не съм тествал никое от тези "би
трябвало" де :)

Иначе се появи идея да питаш LVM-а (може би device mapper-ът има
интерфейс за това) кои точно части от volume-а са allocated и да си
направиш много просто инструментче, което прави writev() с нули върху
тях (или discard за тях, но това не е сигурно, че ще стане както трябва
върху HDD).

Поздрави,
Петър

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Neter 
Дали си обърнал внимание, че sparse в dd се отнася за input-а, а не за 
output-а, и дали това не е причината да си се спънал с него? Но може и точно 
това отношение да „обърнеш“ (в кавички, защото няма да е точно обръщане), 
като patch-ваш dd, за да сработи за целта.


Между другото, щом става дума за SSD, да напомня, че ще имаш полза за 
скоростта на изпълнение, ако пуснеш няколко процеса да трият различни части 
от диска, независимо дали с dd, xxd или каквото там решиш да ползваш.


На 20.02.2018 03:46, Marian Marinov написа:
За съжаление, имплементацията на sparse, директно skip-ва(lseek (fd, size, 
SEEK_CUR) ) целият диск след това записва веднъж :(


___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Marian Marinov 
On 02/20/2018 02:24 AM, Peter Pentchev wrote:
> On Tue, Feb 20, 2018 at 01:01:10AM +0200, Marian Marinov wrote:
>> Ти същото можеш да направиш и с dd if=/dev/zero of=/dev/something.
>> Проблемът и на двата подхода е, че записва нулите на диска и така унищожава 
>> benefit-а на thinpool-а.
> 
> Погледни пак това, което Neter е писал.  Това презаписва само парчетата,
> които *не са* нули.  Няма да е много ефективно, по-ефективно ще бъде
> да се пренапише dd, но все пак ще свърши работа с по-малко усилия.

Прав си. И ти и Neter!

Утре ще пусна по-голям тест.

Аз по-рано бях пробвал:  dd if=/dev/zero of=/dev/coregroup/mm conv=sparse 
bs=4096

За съжаление, имплементацията на sparse, директно skip-ва(lseek (fd, size, 
SEEK_CUR) ) целият диск след това записва веднъж :(

И аз като Пенчев, колная повече към patch на dd :)
Изглежда точно около C_SPARSE ще е удобно за новият код.

Мариян

> 
> Поздрави,
> Петър
> 
> 
> 
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
> 




signature.asc
Description: OpenPGP digital signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Peter Pentchev 
On Tue, Feb 20, 2018 at 01:01:10AM +0200, Marian Marinov wrote:
> Ти същото можеш да направиш и с dd if=/dev/zero of=/dev/something.
> Проблемът и на двата подхода е, че записва нулите на диска и така унищожава 
> benefit-а на thinpool-а.

Погледни пак това, което Neter е писал.  Това презаписва само парчетата,
които *не са* нули.  Няма да е много ефективно, по-ефективно ще бъде
да се пренапише dd, но все пак ще свърши работа с по-малко усилия.

Поздрави,
Петър

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Marian Marinov 
Ти същото можеш да направиш и с dd if=/dev/zero of=/dev/something.
Проблемът и на двата подхода е, че записва нулите на диска и така унищожава 
benefit-а на thinpool-а.

За да стане по-ясно, нека приемем, че имаме едно SSD върху което има един 
единствен partition направен на LVM Physical Volume.
Този PV се използва в една VG, където сме направили thinpool.

В thinpool-а се прави partition от да кажем 500GB но SSD-то е 1TB.
Сега правим snapshot на 500GB partition-а, който е пълен с да кажем 100GB данни 
и реално сме с не повече от 102GB данни, заради това, че цялото нещо е 
направено в thinpool-а.

Проблемът е, че ако направим още 4-5 такива snapshot-а и те не си използват 
пространството през целият си живот, то ако в един момент от времето решим да 
scrub-нем два volume-а ще напълним на 100% corepool-а и ще го счупим :(

Ние имаме защита за това, но остава въпросът, как да ги scrub-на тези volumes?

А какво ще стане ако нямам място да scrub-на дори един от тези 500GB partitions?

Всяко нещо, което записва по всички блокове на /dev/something ще увеличи 
snapshot-а до пълната големина на logical volume-а, затова и търся нещо, което 
да пипа единствено блоковете, които имат данни различни от 0.


On 02/19/2018 11:31 PM, Neter wrote:
> Добре де, ами какво се случва, ако се изпълни това в прикачения файл 
> (неизвестно защо клиентът ми не ще да го изпрати вписано в тялото на 
> писмото)? Сигурен съм, че може да се напише и по-кратко, но за идеята :)
> 
> На 19.02.2018 16:36, Marian Marinov написа:
>> Здравейте група,
>> рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един 
>> казус над който можем да "медитираме" заедно :)
>>
>>
>> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в нашата 
>> система, но предвид, че използваме thinpools се получава следният неприятен 
>> казус.
>> Ако thinpool-а е на 85% и някой си направи много голям volume, докато този 
>> volume не е много пълен системата няма проблем.
>> Но в момента в който клиента си изтрие container-а ние започваме да 
>> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да 
>> препълним thinpool-a :(
>>
>> Ta въпросът ми е, сещате ли се за начин по който да се запишат данни върху 
>> един partition/logical volume, само върху секторите в които реално има данни 
>> :)
>>
>> По принцип chunksync & casync прават подобен анализ на volume-а и копират 
>> само разликите, но на мен ми трябва вместо разлики да се записват данни, пък 
>> било то и нули.
>>
>> Аз в момента обмислям дали да patch-на dd, да има опция която да му казва да 
>> прочете блокчето и ако там няма данни да не записва нищо или да напиша 
>> fstool, който да чете fs table-а и да overwrite-ва само блоковете, за които 
>> FS-а знае, че има данни.
>>
>> Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на 
>> негово място(на неговите blocks) няма нови данни, това означава, че ще 
>> пропусна да scrub-на тези данни.
>>
>>
>> Поздрави,
>> Мариян
>>
>>
>> ___
>> Lug-bg mailing list
>> Lug-bg@linux-bulgaria.org
>> http://linux-bulgaria.org/mailman/listinfo/lug-bg




signature.asc
Description: OpenPGP digital signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Neter 
Добре де, ами какво се случва, ако се изпълни това в прикачения файл 
(неизвестно защо клиентът ми не ще да го изпрати вписано в тялото на 
писмото)? Сигурен съм, че може да се напише и по-кратко, но за идеята :)


На 19.02.2018 16:36, Marian Marinov написа:

Здравейте група,
рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един 
казус над който можем да "медитираме" заедно :)



Ние scrub-ваме дисковете на всички containers, които се destroy-ват в нашата 
система, но предвид, че използваме thinpools се получава следният неприятен 
казус.
Ако thinpool-а е на 85% и някой си направи много голям volume, докато този 
volume не е много пълен системата няма проблем.
Но в момента в който клиента си изтрие container-а ние започваме да 
scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да 
препълним thinpool-a :(


Ta въпросът ми е, сещате ли се за начин по който да се запишат данни върху 
един partition/logical volume, само върху секторите в които реално има данни 
:)


По принцип chunksync & casync прават подобен анализ на volume-а и копират 
само разликите, но на мен ми трябва вместо разлики да се записват данни, пък 
било то и нули.


Аз в момента обмислям дали да patch-на dd, да има опция която да му казва да 
прочете блокчето и ако там няма данни да не записва нищо или да напиша 
fstool, който да чете fs table-а и да overwrite-ва само блоковете, за които 
FS-а знае, че има данни.


Проблемът на вторият подход е, че ако даден файл е изтрит от FS-а и на 
негово място(на неговите blocks) няма нови данни, това означава, че ще 
пропусна да scrub-на тези данни.



Поздрави,
Мариян


___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bgxxd /dev/something | grep -v '       ' | cut 
-d: -f1 | while read i; do echo "$i:        " | 
xxd -r - /dev/something; done
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Marian Marinov 
On 02/19/2018 09:51 PM, Peter Pentchev wrote:
> On Mon, Feb 19, 2018 at 04:36:21PM +0200, Marian Marinov wrote:
>> Здравейте група, рядко вече се обсъждат интересни теми тук, но мисля да
>> ви предложа един казус над който можем да "медитираме" заедно :)
>>
>> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
>> нашата система, но предвид, че използваме thinpools се получава следният
>> неприятен казус.  Ако thinpool-а е на 85% и някой си направи много голям
>> volume, докато този volume не е много пълен системата няма проблем.  Но
>> в момента в който клиента си изтрие container-а ние започваме да
>> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да
>> препълним thinpool-a :(
> 
> Само бих искал да спомена, че ако storage системата, която ползвате,
> използва log-structured writes, няма никакъв смисъл да overwrite-вате
> данните: новите записи ще отидат на съвсем ново място върху диска, изобщо
> няма и да се опитат да презапишат старите данни.

За съжаление не на всякъде използваме Storpool :) и там където е с LVM, това си 
е валиден казус.


> 
> Поздрави,
> Петър
> 
> 
> 
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
> 




signature.asc
Description: OpenPGP digital signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Disk scrubbing

2018-02-19 Thread Peter Pentchev 
On Mon, Feb 19, 2018 at 04:36:21PM +0200, Marian Marinov wrote:
> Здравейте група, рядко вече се обсъждат интересни теми тук, но мисля да
> ви предложа един казус над който можем да "медитираме" заедно :)
> 
> Ние scrub-ваме дисковете на всички containers, които се destroy-ват в
> нашата система, но предвид, че използваме thinpools се получава следният
> неприятен казус.  Ако thinpool-а е на 85% и някой си направи много голям
> volume, докато този volume не е много пълен системата няма проблем.  Но
> в момента в който клиента си изтрие container-а ние започваме да
> scrub-ваме с dd и реално пълним цеият капацитет и можем без да искаме да
> препълним thinpool-a :(

Само бих искал да спомена, че ако storage системата, която ползвате,
използва log-structured writes, няма никакъв смисъл да overwrite-вате
данните: новите записи ще отидат на съвсем ново място върху диска, изобщо
няма и да се опитат да презапишат старите данни.

Поздрави,
Петър

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg