Am 15.01.23 um 16:42 schrieb Wols Lists:
On 15/01/2023 14:48, Reindl Harald wrote:
Am 15.01.23 um 15:43 schrieb Pascal Hambourg:
On 15/01/2023 at 13:13, Reindl Harald wrote:
Am 15.01.23 um 13:00 schrieb Pascal Hambourg:
Linux RAID supports TRIM/discard, but what does it do exactly ?
Does it only pass-through TRIM/discard information to the
underlying devices or can it also store information about which
blocks contain valid data in the superblock metadata?
pass-through TRIM/discard
it makes no sense to store that on the RAID layer
Wouldn't it make sense to:
- skip the initial sync at array creation
- only resync valid data areas during array resync
- reduce wear caused by useless writes on flash drives
- enable TRIM/discard with parity RAID levels by default without
relying on the underlying device capability to return zeroes on read
after TRIM
- ignore mismatches in invalid data areas when scrubbing
it would make sense but it's out of question the way mdadm is
implemented today - just store the information without a proper
usecase would make things only worser
the intentional design of mdadm is a pure RAID implementation on the
device layer with no konwledge of the filesystem on top
And that's the whole point of TRIM. It tells mdadm absolutely nothing
about the file system above APART FROM which part of the array is in use
exactly what i said
everything you listed above has an answer and that's ZFS/BTRFS which
has RAID-functionality by design as part of the FS and hence knows
implcit that unused space don#t need to be mirrored
"skip the initial sync at array creation" - surely, would be nice, but
the design is "we don't know what is stord in thea RAID, our job is
that in RAID1 all mirros are identical at the phyiscal disk layer"
But what we DO know, is that when the array is *created* THERE IS
NOTHING STORED IN THE ARRAY
but we do not know if the drive is completly empty and would bypass a
direct compare of A versus B without null it
TRIM is the mechanism used for one layer (any layer) to tell the layer
below what part of the block device is in use. If raid can use TRIM to
keep track of what blocks carry valid data, and what blocks contain
garbage, then the raid itself can be much more efficient and pro-active
at protecting that data.
but the topic is "What DOES TRIM/discard in RAID do"
You come over very much as believing that md-raid *should* *not* be
improved.
where did i say that?
you came over the same way as i asked why don't work "write-mostly" for
RAID10 while it does for RAID1 when you want to mix SSD/HDD
and you even came up the first posts like you are a developer while you
are just a ordianry user like me
Is it really that perfect?
did i say that?
Some of us are looking for
opportunities
look for opportunities in your own threads about that opportunities and
not in questions about state of play
to improve things, and actively supporting TRIM at the
raid level is such an obvious advance ...
but that is NOT the topic of a question "What DOES TRIM/discard in RAID do"
DOES versus COULD DO
Whether it's worth the effort is a different question ... :-)
it's an important question because someone has a) to do the work b) god
beware of errors in that context and c) the world is not SSD only
Can I ask a favour. STOP POURING COLD WATER ON OTHER PEOPLES' IDEAS. It
doesn't achieve anything, and drives people away!
the topic was "oes it only pass-through TRIM/discard information to the
underlying devices or can it also store information about which blocks
contain valid data in the superblock metadata"
if you want to discuss something else for the sake of god start your own
thread and leave me in peace
