>From: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>
>Dean Roehrich a écrit:
>> We already know know that it's a mistake to rely on the fsid, and file
>> handles, being persistent across remounts--the mkfs/restore thing.
>
>Ok, If you think so...
In practice, they're basically consistent--until someone does a mkfs/restore.
If your filesystem of choice doesn't have an fsid, then you could just
generate one that is valid while the filesystem is mounted and is not written
to the filesystem, or you could come up with something else. Whatever you
choose for an fsid should fit into a 64-bit type.
>> It's starting to get away from us now, isn't it?
>>
>> Maybe we could come back to vector thing later, but we could send the fsid a
>s
>> a parameter to dm_send_mount_event(), I think, and get rid of ->get_fsid().
>
>No, I totally agree for removing the vector stuff and get_fsid. I think
I was referring to the idea of having the vector passed as an argument to
dm_send_mount_event(). I think maybe this would have to be done anyway, if
the two ops vectors (struct filesystem_dmapi_operations and dm_fsys_vector_t)
are unified. It's the only way I can see right now to get some of the
necessary ops available early enough for an HSM to process the MOUNT event,
given that there would be just one ops vector instead of two.
So forget what I said about putting it off :)
>I'd just wonder it whatever
>will be left from the vector_map clean up could integrated in the fsreg
>stuff... Maybe not, I haven't check.
In thinking about this one again, the fsid is still the preferred key to what
we know as the dm_fsreg_t list. That idea about switching to using the sb
pointer value as the key won't fly in a distributed environment.
>Could you try to sum up how and what improvements you see for all of
>this ? How this will be done :) ?
Okay, let's try any of these and see what falls out:
1) The fsid should be a parameter to dm_send_mount_event() and
dm_send_namesp_event() and dm_send_unmount_event().
The get_fsid op in struct filesystem_dmapi_operations should be
dropped.
2) The dm_fsys_vector_t should be folded into struct
filesystem_dmapi_operations. The new ops vector should be
a parameter to dm_send_mount_event().
The part where today we copy the ops vector from
fsys_function_vector_t to dm_fsys_vector_t seems cumbersome and
just makes things hard to understand, so maybe
that copy should be skipped and some of these datatypes could
be removed.
The get_fsys_vector op in struct filesystem_dmapi_operations should be
dropped.
3) It would be nice to keep in mind distributed filesystems and stackable
filesystems; try to make it easier, not harder, to move in those
directions. Unfortunately, I have no experience with the Linux
view of stackable filesystems and I don't quite know how to approach
that problem.
4) The new, unified, ops vector should be kept on a
per-filesystem-instance basis, rather than one ops vector to be
shared by all filesystems.
Does that sum up the things that interest you?
Dean
|