Re: Disk scrubbing

browseman <[email protected]> Sun, 4 Mar 2018 10:54:45 +0200
Newsgroups	gmane.linux.region.bulgaria
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--===============3997132008989448663==
Content-Type: multipart/alternative;
 boundary="------------FB4F6950C649C6FF156514B8"
Content-Language: bg

This is a multi-part message in MIME format.
--------------FB4F6950C649C6FF156514B8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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-R/uZOSXD/[email protected]
> 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.


--------------FB4F6950C649C6FF156514B8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 02/19/2018 04:36 PM, Marian Marinov
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:e0cd995e-59eb-1dc3-a0ac-0b3c892b7cf2-NV7Lj0SOnH0@public.gmane.org">
      <pre wrap="">Здравейте група,
рядко вече се обсъждат интересни теми тук, но мисля да ви предложа един казус над който можем да "медитираме" заедно :)


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

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

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

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

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


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

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Lug-bg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Lug-bg-R/uZOSXD/[email protected]">Lug-bg-R/uZOSXD/[email protected]</a>
<a class="moz-txt-link-freetext" href="http://linux-bulgaria.org/mailman/listinfo/lug-bg">http://linux-bulgaria.org/mailman/listinfo/lug-bg</a>
</pre>
    </blockquote>
    <p>Привет<br>
      <br>
      Аз имам следното доста баламско предложение за решение на казуса,
      може би няма да е приложимо в конкретният случай, но все пак ще
      споделя идеята:<br>
      <br>
      - монтира се дяла в произволна директория<br>
      - изпълнява се нещо от сорта "#find /path/to/mounted/thinvol -xdev
      -type f | xargs shred -n1 -z -u", като разбира се ще има проблеми
      с файлове съдържащи интервали или други специални символи в името
      си, но все сравнително лесно решими - IMHO.<br>
      - изтриват се всички директории<br>
      - демонтира се и в/у дяла се изпълнява mkfs.{FS_TYPE}
      /dev/mapper/thinvol (с цел да се затрият и мета-данните от
      файловата система) - може и да има по-хитър начин, но поне аз не
      се досещам.<br>
      <br>
      Потенциален проблем ще има, ако съществува голям sparse, който
      неминуемо ще доведе до заемане на повече място от колко реално е
      използвал.<br>
      <br>
      <br>
      73.<br>
    </p>
  </body>
</html>

--------------FB4F6950C649C6FF156514B8--

--===============3997132008989448663==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Lug-bg mailing list
Lug-bg-R/uZOSXD/[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg

--===============3997132008989448663==--