On 02/20/2018 08:31 PM, Vladimir Vitkov wrote: > Все още никой не е споменал една деебна особенност на ssd-тата. Именно че не > са хддта и че имат FTL и че няма гаранция това което ти казва чипа да е > истина. Даже по сигурно е че е лъжа. > > Друго предложение: защо не криптираш дяловете при създаване. Новият ключ дори > да е върху същите физически блокове ги прочита като боклук.
Криптирането, предвид, че променя данните, няма ли реално да напълни дяла? Предполагам визираш LUKS? > > On Feb 20, 2018 16:46, "Marian Marinov" <m...@yuhu.biz > <mailto:m...@yuhu.biz>> 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 <mailto:Lug-bg@linux-bulgaria.org> > > http://linux-bulgaria.org/mailman/listinfo/lug-bg > <http://linux-bulgaria.org/mailman/listinfo/lug-bg> > > > > > > _______________________________________________ > Lug-bg mailing list > Lug-bg@linux-bulgaria.org <mailto:Lug-bg@linux-bulgaria.org> > http://linux-bulgaria.org/mailman/listinfo/lug-bg > <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
