Hello, Mikhail Karpov, le ven. 19 juin 2026 23:44:27 +0700, a ecrit: > What I meant was that even if I pass -T typed part:1:file:/root/disk.img to > the translator, running ls or cd in the translator directory will create a > single partition file, and storeio and storeio/1 are the same thing. I find > this behavior confusing, since a partition can't be considered a disk, and > therefore the translator shouldn't be a directory.
Yes, that looks confusing to me. To the user, it would mean that partition 1 itself contains a partition table. Can't we disable the directory facet when there is no actual partition table in the store being driven? > > Ah, libtrivfs doesn't actually call it, that's possibly why we never saw > > the problem. I guess it gets stuck because maptime_map tries to open > > /dev/time, because netfs_init tries with use_mach_dev=0 first. That > > being said libdiskfs does that too. > Storeio will likely need to be added to the bootstrap chain to solve this > issue. That's the only thing that comes to mind. Well, yes, but I meant that netfs_init could be made to call with use_mach_dev=1 first, that would succeed. What I'm surprised is why libdiskfs doesn't have the issue. > > > There are also several functions that I don't understand how to migrate > > > correctly: trivfs_goaway, trivfs_modify_stat, close_hook, and > > > trivfs_S_fsys_syncfs. Am I correct in assuming that these > > > manipulations need to be performed on each open dev? > > > > For goaway/close/sync, yes. modify_stat is only for trivfs > This caused some complications. Previously, each netnode contained a pointer > to an open struct and called open_create when accessing the translator, but > it wasn't clear where and when to call open_free. Furthermore, it was > unclear > how to work with storeio from different peropens. > I propose the following: add netfs_peropen_create_hook and > netfs_peropen_destroy_hook to libnetfs, which will be called by > netfs_make_peropen and netfs_release_peropen, respectively. Now, a netnode > contains a dev and an open_list, which is a list of peropen and open > pointers. You mean, like trivfs already supports? Yes, why not. Having a single-chained open_list is however problematic for efficiency. But actually, why separating struct open from netfs' struct peropen? netfs' peropen already has the filepointer field for the offset. In po->np->nn->dev you have the dev. And libnetfs usually uses po->np->lock as lock. You need really only nperopens to know whether the store is active. I'm also wondering if we want to plug at the netfs_S_io_read layer, or rather at the netfs_attempt_read layer, since the latter would probably be simpler? And similar for other operations. > I have two questions: > 1. The code contains numerous conditions whose results are highly likely to > be > unambiguous. Perhaps it's worth using __builtin_expect to help the branch > predictor perform better? Unless it's really performance-critical code (such as tight loops etc.) it's not really worth cluttering the code with such hints. The compiler also usually already puts fast-exit stances away of the hot path. And the processor's branch prediction will figure it out if the code is run several times. > 2. During development, I added a debug macro that logs code execution. While > this is very convenient for debugging and doesn't make it into the final > code > without the DEBUG flag, is it too much? Or, conversely, should I add logging > everywhere? The mileage will always vary. You would probably want to keep the debug lines for things that might easily break later. For things that will probably be alright on the long run, it's not really worth keeping them. Samuel
