rob05c commented on issue #8713: URL: https://github.com/apache/trafficserver/issues/8713#issuecomment-1064688035
> Ok, basically ATS doesn't even need any sort of FS for caching if it's interacting directly with the block devices. Right. To use a block device, don't put a filesystem on the hard drive, and give ATS the raw block device as the cache, e.g. `/dev/sdd` (or whatever your drive is mounted as). So your `storage.config` will look something like: ``` /dev/sdd volume=1 /dev/sde volume=2 ``` Where `/dev/sdd` and `/dev/sde` are your hard drives, and you have configured volumes `1` and `2` in `volume.config`. See: https://docs.trafficserver.apache.org/en/latest/admin-guide/files/storage.config.en.html https://docs.trafficserver.apache.org/en/latest/admin-guide/files/volume.config.en.html > if ATS interacts with the hardware directly, how are FS's introducing an overhead? You can give ATS either file(s) or block device(s) for cache. If you give it a file, that file resides on a filesystem, and ATS's interactions with it come with all the overhead of the FS. If you give it a raw block device (e.g. `/dev/sdd`), there is no filesystem or corresponding overhead. * _Technically_ the block device isn't interacting directly with the hardware, it's still going thru the Linux Kernel. To interact directly with hardware, you'd need to write a device driver and/or kernel module. But I don't think that distinction is relevant here; ATS doesn't support that, and it'd be very little performance gain for enormous development cost. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
