Re: [Lug-bg] Disk scrubbing

[Marian Marinov <mm@xxxxxxxx>]

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

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

> 
> On Feb 20, 2018 16:46, "Marian Marinov" <mm@xxxxxxxx <mailto:mm@xxxxxxxx>> 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@xxxxxxxxxxxxxxxxxx <mailto:Lug-bg@xxxxxxxxxxxxxxxxxx>
>     > http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg>
>     >
> 
> 
> 
>     _______________________________________________
>     Lug-bg mailing list
>     Lug-bg@xxxxxxxxxxxxxxxxxx <mailto:Lug-bg@xxxxxxxxxxxxxxxxxx>
>     http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg>
> 
> 
> 
> _______________________________________________
> Lug-bg mailing list
> Lug-bg@xxxxxxxxxxxxxxxxxx
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>

Attachment: signature.asc
Description: OpenPGP digital signature

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