Open krizhanovsky opened 9 years ago
Actually, there is no application for the file system. Web cache, as well as Web content files, are HTTP header and response/content body compilation with binary data. So the files aren't suitable for user reading and modifications. The data and HTTP headers binary representation are not trivial to represent to a user. Such records representation are more suitable for databases, so tdbq
should be used instead. Also it'd be hard, at least not fast, to recreate directory tree from URIs of stored Web cache entries.
The binary representation is required to avoid overheads like Nginx has: parsing of raw text representation of cached HTTP headers, storing HTTP headers in Web cache which always are rewritten, hash lookups to get suitable Content-Type for a serviced file etc.
Also consider this nice presentation about HTTP proxy servers. ATS uses lovely database-like approach for Web-cache. File system databases for Web cache looks too old school.
Actually we do need the filesystem, but for other purpose - provide mmap() and msync() interfaces to tdbq for faster true zero-copy data access.
Also tdbfs could be a good point for containers isolation, so containers, just like they do this with filesystem, can load and manage their web content with Tempesta FW in isolated way.
tdbfs may provide directory-based per-vhost configuration like Apache's .htaccess
- the vhost-specific configuration files must be dynamically reloaded along with the main configuration file (see #67). In this sense the file based access in only an interface for a user.
tdbfs must provide user/group access control.
We need Tempesta DB filesystem interface such that Web cache and content files can be commonly written to file system directory, but preprocessed and stored in TDB for immediate transfer.
The file system is just an interface for TDB. Each table should have
fs
option which allows/prohibits its mounting and defines view of the mounted table. Basically, all table records should be shown as files in the same directory. The record key should be used as file name, while the file should contain the rest of record fields in binary (as is
) form.