Support Requests - CLICK TO READ BEFORE POSTING


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

asa drives do not mount
#11

(06-16-2026, 03:15 PM)stevef Wrote:  
scamidge Wrote:by no access I mean it did not mount.
What exactly did not mount ?

Does Linux Lite on your system boot ok ?

Sorry, I did not see this. LL boots. Two internal ata 4T drives did not show in the drives section of Thuner and did not mount at startup. AI recommended switching to a method of mounting based on UUID. Poli something. 

And I added to startup items this code: "sh -c "sleep 5 && udisksctl mount -b /dev/disk/by-uuid/b69fe174-b930-47dd-add6-5f154bb35a7e && udisksctl mount -b /dev/disk/by-uuid/8f5a9fdd-9386-4752-ad0b-3e75e50a5400"

Now the drives mount but when I use grsynch, it is much slower than Zorin was. So AI said to add noatime to UUID. Post #7 gave the rest of the information I have.
Reply
#12

To be completely clear, when booting Linux Lite, do the 4TB drives automount the way you want them to on each boot ?

stevef
clueless
Reply
#13

(06-16-2026, 05:48 PM)stevef Wrote:  To be completely clear, when booting Linux Lite, do the 4TB drives automount the way you want them to on each boot ?

yes but not the normal way and they are slow with grsynch. Both show /run/media/steve/ before the drive label.
Reply
#14

scamidge Wrote:yes but not the normal way and they are slow with grsynch. Both show /run/media/steve/ before the drive label.
Unless a drive has a specific entry in fstab the system will typically mount it under /run/media/yourusername/
From what I've seen there is no entry in your Linux Lite fstab for either of the 4TB drives so the mount point seems ok to me.  When you say they automount 'but not the normal way', I'm guessing you are referring to the fact that you've added the startup instruction.  This shouldn't be a problem. It is unconventional - especially for a non-technical user - but if it works, it works.

If you really want not to use the startup command (as per your original post) then I'm quite willing to try to help but using a forum for this kind of thing can be pretty awkward. The quickest thing may be to re-install, but as far as I can tell from what you've said, the system is functional.  It's your call on this - let me know.

Moving on to the performance issue.  File system synchronization is a complex operation so it is important to be sure to compare like with like.
 
What exact grsync operations are you comparing to determine the performance difference ?
How are the file systems (disks) involved in the comparison operations interconnected ?

stevef
clueless
Reply
#15

(06-16-2026, 06:50 PM)stevef Wrote:  
scamidge Wrote:yes but not the normal way and they are slow with grsynch. Both show /run/media/steve/ before the drive label.
Unless a drive has a specific entry in fstab the system will typically mount it under /run/media/yourusername/
From what I've seen there is no entry in your Linux Lite fstab for either of the 4TB drives so the mount point seems ok to me.  When you say they automount 'but not the normal way', I'm guessing you are referring to the fact that you've added the startup instruction.  This shouldn't be a problem. It is unconventional - especially for a non-technical user - but if it works, it works.



If you really want not to use the startup command (as per your original post) then I'm quite willing to try to help but using a forum for this kind of thing can be pretty awkward. The quickest thing may be to re-install, but as far as I can tell from what you've said, the system is functional.  It's your call on this - let me know.

Moving on to the performance issue.  File system synchronization is a complex operation so it is important to be sure to compare like with like.
 
What exact grsync operations are you comparing to determine the performance difference ?
How are the file systems (disks) involved in the comparison operations interconnected ?
If it is functional and not a threat to stability - fine. I do not want to waste time re-installing or undergoing a difficult fix.

For the timing difference, I am comparing grsynch copying some folders to an external drive (usb hard drive and usf flash drive) with the delete at destination on. On Zorin it is quicker. Example: flash drive on Zorin 4 minutes, on LL 13 minutes.
Reply
#16

A file system synchronization application isn't the best bench-marking tool, but assuming  the test folders are the same in both test, that's quite a difference.

Which of the four drives are the test folders on ?

stevef
clueless
Reply
#17

Storage
Reply
#18

Can you confirm the following is a fair understanding please ?

OS 1 is Zorin installed on Patriot P220
OS 2 is Linux Lite installed on WDS500G3X0C
Source drive is a WD40EZRZ called Storage
Destination drive is some form of USB drive used as fifth disk,
A selection of folders on the Source drive are used as the test data.

Some things need clarification.
Please confirm grsync version in both environments. (Open grsync, click 'Help' then 'About')
grsync options like compression, check summing etc have significant performance impacts.  Please check and confirm all grsync options are exactly the same in both environments.
Please confirm exactly the same selection of source folders are used in both tests.
Please confirm that the contents of the selection of folders is fixed throughout and approximately how  many bytes need to be transferred from source to destination
Please confirm the same fifth disk is used in both tests and that you are sure the destination fifth disk is always manually cleared before each grsync run.  .

stevef
clueless
Reply
#19

Zorin version 1.3
Linux Lite version 1.3.1
grsync options same

contents same - same set of folders - they were, but now LL scripts have changed to settings - they corrupted (I've seen this before, I am not reconstructing again!)

manually cleared - same disk, not cleared,this is backup that is updated every backup
Reply
#20

scamidge Wrote:contents same - same set of folders - they were, but now LL scripts have changed to settings - they corrupted (I've seen this before, I am not reconstructing again!)
Sorry but I don't understand, can you re-phrase this please?
scamidge Wrote:manually cleared - same disk, not cleared,this is backup that is updated every backup
Not sure I understand this.

To compare the results properly both tests must do the same thing.
If the destination directories are known to be empty before running the synchronization then at least both systems have the same starting point.  If the destination are not empty, then the file synchronization tool needs to calculate what to copy (based on the session settings) and the transfers will be different.

stevef
clueless
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)