Thanks for the comments.
On Thu, Mar 17, 2022 at 12:37 PM Steve Dickson <steved@xxxxxxxxxx> wrote:
> I think it might make sense to added some examples
> on how the command will be used.
Will do.
> Would it make sense to try added these to nfs.conf?
>
> I must admin I'm a bit impressed with your lex and
> yacc routines in patch 5, I have not seen those
> in a while.. but that does add more dependencies
> to nfs-utils and as well as yet another config file
> to manage.
I debated with a funko pop between writing the parser and using a parser
builder. Originally, the idea was to provide more possibilities, like
configuring the read ahead of other devices, but those BDIs don't
announce themselves when they are added like NFS does. I also don't know
how useful it would be. So this idea is scrapped for now.
Here are the debate conclusions:
- writing the parser would add some complexity that lex/yacc handles
- lex/yacc add build time dependencies and some bloat
- error handling is painful with lex/yacc
- lex/yacc are well known
- using a parser combinator would be my preference, but I couldn't
find any written in c that didn't add a new library to the systems
It seemed to me that using lex/yacc was the best choice taking into
account the needs of both limited storage systems and large servers.
I can still see some configurations that may be added in the future,
like setting the read ahead per server, network segment, but I believe
that the configurations we have cover most of the use cases.
I've added a new configuration because I planned to have a more fine
grained configuration for multiple file systems/designs, and that
would add a lot in nfs.conf (and tie the tool to nfs).
And, to be completely honest, I took what I've done in
https://github.com/trbecker/readahead-utils
and ported it to nfs-utils.
That's the history so far. I don't mind taking stuff out if it would
make the software more maintainable.
> steved.
>
thiago
