(Re ** 4)[1]: Extending "thin_trim" (about pseudo-raid)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Mr. Kabelac,

I have (at first) not been aware, that at the end of your mail, you asked
me probably 'about pseudo-raid'. It is difficult for me to give you an
abstract definition of it, so I give you an example:

* splitting the device '8:16' == /dev/sdb into 17 chunks of equal size by
  the following table:

* "dmsetup table ..." --> extended by the mappig 'from the names' to
  /dev/dm-<n> (omitting "dmsetup ls", --> mapping "name -> /dev/dm-<n>"
  in a separate list).
  /dev/dm-20 <-- AFE37B55.A0:  0 86183752 linear 8:16 8
  /dev/dm-21 <-- AFE37B55.A1:  0 86183752 linear 8:16 86183760
  /dev/dm-22 <-- AFE37B55.A2:  0 86183752 linear 8:16 172367512
  /dev/dm-23 <-- AFE37B55.A3:  0 86183752 linear 8:16 258551264
  /dev/dm-24 <-- AFE37B55.A4:  0 86183752 linear 8:16 344735016
  /dev/dm-25 <-- AFE37B55.A5:  0 86183752 linear 8:16 430918768
  /dev/dm-26 <-- AFE37B55.A6:  0 86183752 linear 8:16 517102520
  /dev/dm-27 <-- AFE37B55.A7:  0 86183752 linear 8:16 603286272
  /dev/dm-28 <-- AFE37B55.A8:  0 86183752 linear 8:16 689470024
  /dev/dm-29 <-- AFE37B55.A9:  0 86183752 linear 8:16 775653776
  /dev/dm-30 <-- AFE37B55.A10: 0 86183752 linear 8:16 861837528
  /dev/dm-31 <-- AFE37B55.A11: 0 86183752 linear 8:16 948021280
  /dev/dm-32 <-- AFE37B55.A12: 0 86183752 linear 8:16 1034205032
  /dev/dm-33 <-- AFE37B55.A13: 0 86183752 linear 8:16 1120388784
  /dev/dm-34 <-- AFE37B55.A14: 0 86183752 linear 8:16 1206572536
  /dev/dm-35 <-- AFE37B55.A15: 0 86183752 linear 8:16 1292756288
  /dev/dm-36 <-- AFE37B55.A16: 0 86183752 linear 8:16 1378940040

* having a raid4 with these chunks (see /proc/mdstat):
  md255 : active raid4 dm-36[17] dm-35[15] dm-34[14] dm-33[13] \
          dm-32[12]    dm-31[11] dm-30[10] dm-29[9]  dm-28[8]  \
          dm-27[7]     dm-26[6]  dm-25[5]  dm-24[4]  dm-23[3]  \
          dm-22[2]     dm-21[1]  dm-20[0]
          689438720 blocks super 1.0 level 4, 4096k chunk,     \
          algorithm 0 [17/17] [UUUUUUUUUUUUUUUUU]

  (Ok. its actually "raid4", because distributing reads / writes on diffe-
  rent legs is not sensible, if these legs reside on the same disk.)

* according to them man page "md": MD(4)
  [...]
  In later kernels, a read-error  will  instead
  cause  md  to  attempt a recovery by overwriting the bad block. i.e. it
  will find the correct data from elsewhere, write it over the block that
  failed, and then try to read it back again.
  [Modern hard disks have spare sectors; a defective sector is at least,
  when it is written to,(sorry for my english) replaced by such a spare-
  sector.]
  [...]


Sincerely

Thomas

============================================================================
On Mon, November 18, 2024 10:28 am, Zdenek Kabelac wrote:
> Dne 17. 11. 24 v 11:26 "Thomas Bruecker" napsal(a):
>> [...]
>  [...]
>> [...]
>> * My name: "pseudo-raid": raid5 with legs on the same device, especially
>>   a hard disk. Ok, I admit, its slow.
>>   * Reason:
>>     * Modern hard disks are able to correct defective sectors, if the
>>       driver ('md') knows, what should be in these sectors.
>>     * You may not equip a notebook with additional hard disk.
> Is this some sort of 'raid1 + writemostly' ?
> And there is also another target 'dm-era' - which is however not
> supported (yet)  by lvm2...






[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux