RAM speedup

[Matthias Schniedermeyer]

On 30.06.2020 11:52, Rupert Gallagher wrote:
> ????????????????????? Original Message ?????????????????????
> On Sunday 28 June 2020 21:29, Matthias Schniedermeyer <ms at citd.de> wrote:
> 
> > On 28.06.2020 16:46, Rupert Gallagher wrote:
> >
> > > ????????????????????? Original Message ?????????????????????
> > > On Sunday 28 June 2020 13:58, Matthias Schniedermeyer ms at citd.de wrote:
> > > destination:
> > > ST5000LM000-2AN1 sata hdd
> > > Writing speed : 74 MB/s
> > > Reading speed : 89 MB/s
> >
> > And this HDD is a SMR model(*) on top of beeing a 4k sector model emulating 512 byte sectors.
> > So alignment needs to be correct and the filesystems must use 4k sectors.
> >
> > This HDD is NOT suitable for beeing used for small files and a hardlink-farm.
> >
> > SMR HDDs only reach best performance if used "like a tape drive" with large and linear writing.
> >
> > I use SMR HDDs myself and only use them for "really large" files (>500MB per file), otherwise they perform very poorly.
> > I also align my partitions correctly and set XFS to "4k sector"-size.
> > Which nowadaya means: I use 4k sectors for anything. As i only have been
> > using 4k sector HDDs for nearly as long as they are on the market (IIRC >1 decade).
> >
> > Also SSDs are usually optimized for 4k sectors too.
> >
> > *:
> > https://en.wikipedia.org/wiki/Shingled_magnetic_recording
> 
> SMR is the cost we pay for large storage on small space.
> There is something similar to SMR also for SSD, found in Samsung QVO units.
> 
> The cost-benefit analysis for 2.5" drives led to this product.
> 
> Costs are HDD <= SSD < TAPE (HP LTO Ultrium).
> 
> We are using this disk "like a tape drive", with hardlinks because it can.

You aren't using it "like a tape drive". That would be 'tar'ing the files.
A hardlink-form is very meta-data intensive:
IOW many small reads (if uncached, no 'worse' for SMR than normal HDDs. 
Just "bad" in general for HDDs) and writes (forces the drive to rewrite 
bands, which is counter to what a SMR needs for best performance.
But SMR-drives usually have a cache of "X" GB to catch some amount of 
writes. If your working set is small, you may be in luck that you stay 
within the amount of cache (i mean the cache in the HDD) available and 
the performance doesn't drop like a cliff.

If you have your HDD in ear-range, you can hear it still working after 
finishing a copy. If the drive is IDLEing it will flush it's cache.

For my SMR-drives i wait until they are "silent" (or for an hour max) 
befor sending them to sleep. (`hdparm -y` a.k.a.: "Standby Immediate")

> This is from the current disklabel:
> 
> bytes/sector: 512
> sectors/track: 255
> tracks/cylinder: 511
> sectors/cylinder: 130305
> cylinders: 74959
> total sectors: 9767541168 # total bytes: 4.5T
> 
> This is from the current ffs2:
> 
> fs block size      : 8192 bytes
> Free disk space    : 4713572474880 bytes
> 
> The values are native, without any tuning.
> 
> However, the bottom line is that I get the job done in 2 hours via the lan, and 8 hours via the bus...

Which i find puzzling.
Was that local LAN (@localhost, so still the same machine), or 2 different machines?

If it was 2 different machines, you "gained" the cache that was used for 
caching the read-side beforehand, you also "dropped" the cache-trashing 
from the read-side on write-side.

And did you test the LAN copy, after doing a local copy? (Without 
rebooting inbetween? So some amount of meta-data may have stayed in the 
cache.)?

And did you do the test "back2back" and with/without using the same 
source for link-dest? IOW did the second copy have no or less changes 
"than normal"? (less changes means: Less cache trashing, which improves performance)

hardlink-farms are way faster when the amount of meta-data is smaller 
than the amount of RAM available. For Linux i reduce the 
'vfs_cache_pressure' for it to prefer keeping inode & dentry-data in RAM 
and dropping the content-cache.
So in best-case scenarios the meta-data has only to be read once and 
stays cached.



-- 

Matthias