Re: Status swap.state cleanup; store_dir_{ufs,aufs}.c cleanup

At this stage I think it is more important we concentrate on the API
side of things, and worry about the source layout later.

We haven't even decided yet what levels of Squid constitutes a on-disk
object store system, and even less where the boundaries between
filesystem and I/O code is.

I am pretty sure that once the boundaries are identified, making
makefiles to reflect dependencies on shared components won't be that
hard.

Prime candidates for shared components in the current sources:
* The Squid AIO implementation
* UFS directory maintenance
* State logging

/Henrik

Arjan de Vet wrote:
>
> Hi,
>
> A short update on my cleanup of the swaplog code.
>
> - I've extracted the generic part of the code handling the swap.state
> file into a new file src/store_dir_gen.c.
>
> store_dir_ufs.c and store_dir_aufs.c now reference these generic
> routines. These generic routines should be usable for new SquidFS's as
> well which are too lazy to implement swap.state code themselves :-).
>
> - After extracting the swap.state handling and some code/whitespace
> reshuffeling in store_dir_ufs.c and store_dir_aufs.c these files have
> become almost equal after applying the following script:
>
> cp ufs/store_dir_ufs.c store_dir_ufs.c
>
> cat aufs/store_dir_aufs.c | sed '
> s/asyncufs/aufs/g
> s/ASYNCUFS/AUFS/g
> s/aioinfo/aufsinfo/g
> s/AUFS/UFS/g
> s/Aufs/Ufs/g
> s/aufs/ufs/g
> ' > store_dir_aufs.c
>
> The only real difference left is within storeFsSetup_{ufs,aufs}.
>
> Do you think it's a good idea to see if I can merge these two files
> into one which then provides a generic 'UFS L1/L2 layout' layer on
> which store_io_ufs.c and store_io_aufs.c can build? I'm aware I'm
> reverting some parts of Henrik's work on creating fs/{ufs,aufs} here
> but in the end the amount of duplicate code should be much less than
> it is now.
>
> What we would get is a clean separation of the layout of files on disk
> and the I/O method used to read/write them. This could be reflected as
> follows under the src/fs/ hierarchy:
>
> src/fs/
> src/fs/ufs/ UFS L1/L2 layout layer, contains store_dir_ufs.c
> src/fs/ufs/sync/ I/O layer, synchronous (store_io_ufs.c)
> src/fs/ufs/async/ I/O layer, asynchronous (store_io_aufs.c)
> src/fs/ufs/..../ Adrian's and Chris' new I/O model? :-)
> src/fs/raw/ Raw disk layout layer
> src/fs/raw/sync/ I/O layer, synchronous
> src/fs/raw/async/ I/O layer, asynchronous (my posix_aio_fs proposal)
>
> For example: store_io_ufs.c only uses storeUfsDirFullPath and
> storeUfsDirMapBitReset to interface with the store_dir_ufs.c code and
> it's similar in the aufs case.
>
> What's your opinion? Does the above make sense?
>
> - For the current diff (against 2.3.STABLE1-mod1) see
>
> http://www.iae.nl/users/devet/squid/squidfs/
>
> As I said, it's not finished yet so don't include it in a mod2 or
> something similar yet. Nevertheless, comments and suggestions are
> welcome of course.
>
> Arjan
>
> --
> Arjan de Vet, Eindhoven, The Netherlands <Arjan.deVet@adv.iae.nl>
> URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl
Received on Mon Jan 24 2000 - 19:08:47 MST