Am 15.01.23 um 16:42 schrieb Wols Lists:

On 15/01/2023 14:48, Reindl Harald wrote:

quoted

Am 15.01.23 um 15:43 schrieb Pascal Hambourg:

quoted

On 15/01/2023 at 13:13, Reindl Harald wrote:

quoted

Am 15.01.23 um 13:00 schrieb Pascal Hambourg:

quoted

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

quoted

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