Date: Wed, 20 Nov 2019 11:24:11 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Wojciech Puchar <wojtek@puchar.net>, freebsd-hackers@freebsd.org Subject: Re: geom_ssdcache Message-ID: <f4377080-d94f-04d6-1121-8506ad40b20f@grosbein.net> In-Reply-To: <alpine.BSF.2.20.1911191256330.6166@puchar.net> References: <alpine.BSF.2.20.1911191256330.6166@puchar.net>
next in thread | previous in thread | raw e-mail | index | archive | help
19.11.2019 19:06, Wojciech Puchar wrote: > today SSD are really fast and quite cheap, but still hard drives are many times cheaper. > > Magnetic hard drives are OK in long reads anyway, just bad on seeks. > > While now it's trendy to use ZFS i would stick to UFS anyway. > > I try to keep most of data on HDDs but use SSD for small files and high I/O needs. > > It works but needs to much manual and semi automated work. > > It would be better to just use HDD for storage and some of SSD for cache and other for temporary storage only. > > My idea is to make geom layer for caching one geom provider (magnetic disk/partition or gmirror/graid5) using other geom provider (SSD partition). > > I have no experience in writing geom layer drivers but i think geom_cache would be my fine starting point. At first i would do read/write through caching. Writeback caching would be next - if at all, doesn't seem good idea except you are sure SSD won't fail. > > But my question is really on UFS. I would like to know in geom layer if read/write operation is inode/directory/superblock write or regular data write - so i would give the first time higher priority. Regular data would not be cached at all, or only when read size will be less than defined value. > > Is it possible to modify UFS code to pass somehow a flag/value when issuing read/write request to device layer? I can't really help you with your questions but you could look at geom_cache we already have. It allows to dedicate additional RAM to the cache layer and more important, it can place lower limit on size of read requests to lower layer (disk) that may be important for providers which performance degrades because of short reads (USB2 device or RAID3). Be warned that geom_cache has some unresolved issues: if system has more than single active GEOM_CACHE provider, it may corrupt metadata. It still may serve as example, just don't trust it blindly. I use it for two-terabyte USB 2.0 HDD connected to my small home router (UFS-only). Also note that such media brings new type of operation other than BIO_READ/BIO_WRITE: BIO_DELETE. For SATA-based SSD, BIO_DELETE corresponds to ATA TRIM protocol command. When file systems frees some block, BIO_DELETE must be processed by GEOM layer invalidating part of cache and passed to lower layer. For HDD, large removals (for example, deletion of a snapshot) should be quick but for SSD it may result in massive I/O due to many BIO_DELETE requests. And SSD may be quite slow to process them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f4377080-d94f-04d6-1121-8506ad40b20f>