On 04/13 08:18, Rich Freeman wrote: > On Mon, Apr 13, 2020 at 7:55 AM Michael <confabul...@kintzios.com> wrote: > > > > I have noticed when prolonged fstrim takes place on an old SSD drive of mine > > it becomes unresponsive. As Rich said this is not because data is being > > physically deleted, only a flag is switched from 1 to 0 to indicate its > > availability for further writes. > > That, and it is going about it in a brain-dead manner. > > A modern drive is basically a filesystem of sorts. It just uses block > numbers instead of filenames, but it can be just as complex > underneath. > > And just as with filesystems there are designs that are really lousy > and designs that are really good. And since nobody sees the source > code or pays much attention to the hidden implementation details, it > is often not designed with your requirements in mind. > > I suspect a lot of SSDs are using the SSD-equivalent of FAT32 to > manage their block remapping. Some simple algorithm that gets the job > done but which doesn't perform well/etc. > > This makes me wonder if there would be a benefit from coming up with a > flash block layer of some sort that re-implements this stuff properly. > We have stuff like f2fs which does this at the filesystem level. > However, this might be going too far as this inevitably competes with > the filesystem layer on features/etc. > > Maybe what we need is something more like lvm for flash. It doesn't > try to be a filesystem. It just implements block-level storage > mapping one block device to a new block device. It might very well > implement a log-based storage layer. It would accept TRIM commands > and any other related features. It would then have a physical device > translation layer. Maybe it would be aware of different drive models > and their idiosyncrasies, so on some drives it might just be a NOOP > passthrough and on other drives it implements its own log-based > storage with batched trims on large contiguous regions, and so on. > Since it isn't a full POSIX filesystem it could be much simpler and > just focus on the problem it needs to solve - dealing with brain-dead > SSD controllers. > > -- > Rich > Hi Rich, hi Michael,
THAT is information I like...now I start(!) to understand the "inner mechanics" of fstrim...thank you very much!!! :::))) One quesion -- not to express any doubt of what you wrote Rich, but onlu to check, whether I understand that detail or not: Fstrim "allows" the drive to trim ittself. The actual "trimming" is done by the drive ittself without any interaction from the outside of the SSD. You wrote: > > Now, the drive controller needs to keep track of which blocks are in > > use (which it does whether you use fstrim or not), and that data is > > probably stored in some kind of flash so that it is persistent, but > > presumably that is managed in such a manner that it is unlikely to > > fail before the rest of the drive fails. and: > > Fundamentally trimming is just giving the drive more information about > > the importance of the data it is storing. Just about any filesystem For me (due my beginners level of knowing the "behind the scene" things) this is kinda contradictionous. On the one hand, the SSD drive keeps track of the information, what blocks are used and unused. And trimming is done by the drive in itsself. On the other hand trimming is "just giving the drive more information about...." What kind of information does the commandline tool fstrim transfers to the SSD beside the command "fstrim yourself" (an ioctl, I think?), which is needed to fstrim the blocks and what kind of information is the SDD collecting itsself for this purpose? Cheers! Meino >
