Jiří Zárevúcky <[email protected]> wrote: > > > On Fri, Jan 24, 2025, 23:25 Miroslav Cimerman <[email protected]> wrote: > > > Hello, > > > > I would be grateful for anyone who has an insight > > into the ext4 filesystem and/or VFS. > > > > It would be great to use the maximum IPC data transfer > > size (64K). The maximum size ext4 currently allows > > through is 4K. Would it be ok to just bump the parameters > > to 64K? > > > I'm no expert at ext4, but it seems to me that you are increasing > a parameter of the file system on-disk representation? Does such a > file system work with other operating systems? > And the change won't affect file system created by Linux tools, would it?
I mostly just would like to demonstrate the performance of my RAID on some "real" files/workloads, other than raw block read/writes. I would use it just with mkext4 locally on HelenOS. (but it would probably work elsewhere, the parameters are read from the superblock...) > Anyway, the reason the IPC transfer is limited in such a way is probably > because the file system implementation read/writes only a single block > at a time. The "proper" solution to this would be to check how much of > the transfer is to a single contiguous region and forward that. It's actually of that what the block size is set to, so the default now can only pass 4K at most at once, with my parameters it allows whole IPC xfer size, some numbers: copying 1M file, block size of the underlying blockdev is 512: - ext4 bsize 4K (default): ~256 write calls - ext4 bsize scaled to max xfer: ~16 write calls On bigger workloads the difference is quite noticeable. So it's actually working, I just wanted to know if there is not some flaw or a pitfall with the parameters. Either way I will get it into my tree, so that I can demonstrate some nice features of HelenRAID. But is there a chance my addition could get merged into upstream:master? Can I open a PR? > This is not just an ext4 issue by the way. I think FAT still does transfers > in 512 B blocks. Utterly ridiculous in a system where every call has the > latency of a retired professor responding to e-mails, but nobody has had > the time or interest to fix it yet. Yes, the FAT writing is a joke. exFAT too, as it uses fat_write(). > but nobody has had the time or interest to fix it yet. I would be quite interested to look at it, lately I am more and more interested in performance, and I have some ideas for what could be my Master's thesis :-D Thanks. -- mc _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
