Re: [gentoo-user] Getting maximum space out of a hard drive
On 21/8/22 13:34, Grant Taylor wrote: On 8/20/22 10:22 PM, William Kenworthy wrote: ... If that is an Odroid XU4, then I strongly suspect that /dev/sda is passing through a USB interface. So ... I'd take those numbers with a grain of salt. -- If the system is working for you, then by all means more power to you. I found that my Odroid XU4 was /almost/ fast enough to be my daily driver. But the fan would kick in for some things and I didn't care for the noise of the stock fan. I've not yet compared contemporary Raspberry Pi 4 or other comparable systems. Samsung Exynos 5422 is developed on the 28 nm technology node and architecture Cortex-A15 / Cortex-A7. Its base clock speed is 1.40 GHz, and maximum clock speed in turbo boost - 2.10 GHz. Samsung Exynos 5422 contains 8 processing cores. Instruction set (ISA) ARMv7-A32 (32 bit) ArchitectureCortex-A15 / Cortex-A7 Yes, its an xu4 and as I mentioned, its a USB drive (seagate 4G backup with an SMR inside) - works ok as a backup drive and the data transfer is fast until you fill the cache - then its throughput is best described as "miserable"! The xu4 lists as 32bit and odroid supplies a 32 bit kernel etc - I just used their config as a base when building gentoo onto it - its my build (for 5 xu4 based HC2 systems) and hosts the backup drive. My attaching the hdparm run was an example of its use, and that happened to be the terminal i was using at the time. BillK
Re: [gentoo-user] Getting maximum space out of a hard drive
William Kenworthy wrote: > What are you measuring the speed with - hdparm or rsync or ? > > hdparm is best for profiling just the harddisk (tallks to the > interface and can bypass the cache depending on settings, rsync/cp/?? > usually have the whole OS storage chain including encryption affecting > throughput. Encryption itself can be highly variable depending on > what you use and usually though not always includes compression before > encryption. There are tools you can use to isolate where the slowdown > occurs. atop is another one that may help. > > [test using a USB3 shingled drive on a 32 it arm system] > > xu4 ~ # hdparm -Tt /dev/sda > /dev/sda: > Timing cached reads: 1596 MB in 2.00 seconds = 798.93 MB/sec > Timing buffered disk reads: 526 MB in 3.01 seconds = 174.99 MB/sec > xu4 ~ # > > BillK > I copied that from a fair sized file in rsync's progress output. I just picked one that was the highest in the last several files that were on the screen, without scrolling back. No file system with compression since compressing video files doesn't help much. Just ext4 on encrypted LVM on a single partition. I tell you tho, this new drive is filling up pretty darn fast. I got to build a NAS or something here. Thing is, how to put it somewhere it is protected and all. A NAS won't exactly fit in my fire safe. :/ Bigger fire safe maybe o_O Dale :-) :-) P. S. Just made three more jars of pepper sauce. Must have that to go with peas and cornbread. :-D
[gentoo-user] Re: (G)vim 9.0.0099 won't start
On 2022-08-21, Philip Webb wrote: > Today, I updated to the latest stable Vim 9.0.0099 + GVim same > & it refused to open. No problem back with 8.2.4586. > > Has anyone else encountered this ? Does anyone have a suggestion ? No *vim here, but: what does happen exactly? That is, what do you mean with "refused to open"? Is there any error message? (If it hasn't been started from a terminal or terminal emulator, try that way and see if there is any relevant output.) -- Nuno Silva
Re: [gentoo-user] Getting maximum space out of a hard drive
Dale wrote: > William Kenworthy wrote: >> What are you measuring the speed with - hdparm or rsync or ? >> >> hdparm is best for profiling just the harddisk (tallks to the >> interface and can bypass the cache depending on settings, rsync/cp/?? >> usually have the whole OS storage chain including encryption affecting >> throughput. Encryption itself can be highly variable depending on >> what you use and usually though not always includes compression before >> encryption. There are tools you can use to isolate where the slowdown >> occurs. atop is another one that may help. >> >> [test using a USB3 shingled drive on a 32 it arm system] >> >> xu4 ~ # hdparm -Tt /dev/sda >> /dev/sda: >> Timing cached reads: 1596 MB in 2.00 seconds = 798.93 MB/sec >> Timing buffered disk reads: 526 MB in 3.01 seconds = 174.99 MB/sec >> xu4 ~ # >> >> BillK >> > I copied that from a fair sized file in rsync's progress output. I just > picked one that was the highest in the last several files that were on > the screen, without scrolling back. No file system with compression > since compressing video files doesn't help much. Just ext4 on encrypted > LVM on a single partition. > > I tell you tho, this new drive is filling up pretty darn fast. I got to > build a NAS or something here. Thing is, how to put it somewhere it is > protected and all. A NAS won't exactly fit in my fire safe. :/ Bigger > fire safe maybe o_O > > Dale > > :-) :-) > > Well, 2.5 days later, first backup done. Then I had to restart to update the changes made in the past couple days that rsync didn't catch. When that got done, I wanted to close the drive and unhook it but I'm getting that 'device in use' message. Well, after some digging, I found that extlazyinit process running and if memory serves me, that is the process that creates the file system in the background. I ran into that before. I think it was copying the files as fast as it was able to create the file system to put it on. I'll know next time I do backups. If this thing ever lets me disconnect the drive. Oh. Filesystem Size Used Avail Use% Mounted on /dev/mapper/10tb 9.1T 7.5T 1.6T 83% /mnt/10tb I don't see that lasting to long. :/ Yup, gotta come up with a plan. Dale :-) :-)
Re: [gentoo-user] (G)vim 9.0.0099 won't start : SOLVED
220820 Philip Webb wrote: > Today, I updated to the latest stable Vim 9.0.0099 + GVim same > & it refused to open. No problem back with 8.2.4586. After some sleep & investigation, I found the problem, which is with Gvim. The gtk+ gtk+2 USE flags have been dropped for Gvim-9 , which now defaults to the Motif GUI, which won't start from CLI : "E25: GUI cannot be used: Not enabled at compile time". This cb avoided by using USE="-motif" , which defaults to using Gtk:3 , & Gvim starts from CLI as it should. Gentoo Bug 831250 covers removing the gtk USE flags. I have added a comment as above & we'll see what the devs decide to do. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
