On Mon, Jun 30, 2025 at 7:05 PM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > > Hi, > > 在 2025/06/30 16:25, Xiao Ni 写道: > > On Mon, Jun 30, 2025 at 10:25 AM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > >> > >> Hi, > >> > >> 在 2025/06/30 10:14, Xiao Ni 写道: > >>> For reload action, it runs continue here. > >> > >> No one can concurent with reload. > >> > >>> > >>> And doesn't it need a lock when reading the state? > >> > >> Notice that from IO path, all concurrent context are doing the same > >> thing, it doesn't matter if old state or new state are read. If old > >> state is read, it will write new state in memory again; if new state is > >> read, it just do nothing. > > > > Hi Kuai > > > > This is the last place that I don't understand well. Is it the reason > > that it only changes one byte at a time and the system can guarantee > > the atomic when updating one byte? > > > > If so, it only needs to concern the old and new data you mentioned > > above. For example: > > raid1 is created without --assume-clean, so all bits are BitUnwritten. > > And a write bio comes, the bit changes to dirty. Then a discard is > > submitted in another cpu context and it reads the old status > > unwritten. From the status change table, the discard doesn't do > > anything. In fact, discard should update dirty to unwritten. Can such > > a case happen? > > This can happen for raw disk, however, if there are filesystem, discard > and write can never race. And for raw disk, if user really issue write > and discard concurrently, the result really is uncertain, and it's fine > the bit result in dirty or unwritten. Hi Kuai If there is a filesystem and the write io returns. The discard must see the memory changes without any memory barrier apis? Regards Xiao > > Thanks, > Kuai > > > > > Regards > > Xiao > >> > >> Thanks, > >> Kuai > >> > > > > > > . > > >
