[Discuss] what are pros/cons of different (Linux) filesystems for use with SMR (shingled) hard drives?

[Kent Borg]

On 11/13/20 3:35 PM, Dan Ritter wrote:
> https://www.snia.org/sites/default/files/SDC15_presentations/smr/HannesReinecke_Strategies_for_running_unmodified_FS_SMR.pdf 


I'll have to look at that.


> Super-short TL;DR: rsync is bad. Compressed tar files are good.
> Big writes are good. Small writes are bad. ext4 can be coerced
> into sorta doing a better job; btrfs ought to be better, but is
> worse.
>
> It's not the longevity of the disk which is the problem, it's
> the fact that once you start updating data on the disk, it can
> cause horrendously amazing write amplification and the disk will
> be ridiculously slow as it tries to handle its housekeeping
> tasks while writing your data.

I got into an argument recently with a (silly) friend who thinks 
rotating media is old fashioned and far too slow and SSDs have come down 
in price, I should buy an SSD for backup!

No, I am sure you would not be that silly, but my response still holds: 
I use these disks for off-line backups. Their prime job is to sit there 
most of the time doing nothing, unused. When I do one of my encrypted 
backups I think it takes 20-minutes minimum, (if only a few days worth) 
sometimes several times longer (if it has been weeks). So what? I'm 
likely off doing something else (yes, some risk of version skew between 
different files during the backup if I am using my computer while the 
backup is happening).

Also, realize that this technique writes whole files or makes a hard 
link to an old file. Yes, writing new directory structures is little 
writes, but when I tail -f the log file, that's not what seems to take 
time. Writing big files takes time.


If I had a lot of data streaming in constantly, my solution would be 
completely different. If I had database files, my solution would be 
completely different. But this is just me, not doing much on my computer.


The ease and speed of random access to the link-dest backup contents is 
so nice—particularly if I might be frantic over some other failure. Each 
backup is its own tree, intact and complete. Want a newer version of 
some file, look at a newer tree. Want older, look in an older tree. No 
"How do I access the backup again?" The technique to access the backup 
is largely the same as doing a new backup: plugin, enter key. For the 
backup case, cd into the disk and run my script. For the restore case cd 
deeper, to whatever data I want. My custom script is needed to make a 
backup, but no specialized software is needed to access the backup 
beyond a reasonably recent Linux machine with an appropriate available 
USB port.


-kb