> On 16 Aug 2024, at 21:29, Andre Robatino wrote:
>
> All I know is that my two desktops have the GNOME, KDE, MATE, Cinnamon, and
> Basic DEs installed, and by updating the nemo package to the Bodhi testing
> version, sync was disabled, so there's nothing else in those DEs causing the
> prob
> On 16 Aug 2024, at 19:28, Roger Heflin wrote:
>
> It would depend on the buffer size being used.
The buffer size is not the limit., unless it's lots of GiB in size.
It's the fact that you go into a half-duplex mode that sets the limit.
This pattern slows down all sorts of algorithms, disk
Tim wrote:
> Is it just nemo with the problem? Because that file browser is on
> systems under various different program names (nemo, nautilus, caja)
> with *some* tinkering between the different forks.
All I know is that my two desktops have the GNOME, KDE, MATE, Cinnamon, and
Basic DEs install
On Fri, 2024-08-16 at 19:17 +, Andre Robatino wrote:
> In my case, I didn't have the nemo package installed on my laptop
> (the one with USB 3.0 ports) so sync was never enabled when using
> that machine. The two machines with USB 2.0 ports both have nemo
> installed (as part of the cinnamon de
Roger Heflin wrote:
> It would depend on the buffer size being used. In Andre's case he
> reported it was ok with non-2.0 speeds, probably just luck that the
> buffer on his disk is large enough that it works ok.
In my case, I didn't have the nemo package installed on my laptop (the one with
USB
It would depend on the buffer size being used. In Andre's case he
reported it was ok with non-2.0 speeds, probably just luck that the
buffer on his disk is large enough that it works ok.
In general I have never had good luck with sync providing anything
resembling a decent speed except with raid
> On 16 Aug 2024, at 18:12, Roger Heflin wrote:
>
> So here is why sync sucks only on a usb 2.0 connection.
The report that lead to the revert of the sync change was on 3.0 connections.
The slow down was x10 or more.
So no this is not a USB 2 only issue.
Only if the user program and the USB
So here is why sync sucks only on a usb 2.0 connection.
The host fills up the disks write cache some portion of
(32MB/64MB/128MB) and then the disk waits for the head get to were the
data needs to be written and writes it, as the write cache clears
space the host sends more data, but at usb2.0 the
Installing the nemo Bodhi update from
https://bodhi.fedoraproject.org/updates/FEDORA-2024-4717e54d2b does cause sync
to be eliminated from the line in /proc/mounts, and my transfer speed is back
to normal. Thanks for the replies!
--
___
users mailing
I just checked the laptop and the /proc/mounts line for the portable drive is
/dev/sdb1 /run/media/andre/Seagate btrfs
rw,seclabel,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
and indeed there is no sync! (Otherwise it's identical to the one posted above
from my desktop.) I realize
No, I'm using GNOME, although I do have the cinnamon desktop installed. From
looking at your link it looks like it's due to using sync, next time I boot my
laptop I intend to check if the /proc/mounts shows the portable drive using
sync there, since my transfer speed seems to be normal on that.
> On 15 Aug 2024, at 21:29, Roger Heflin wrote:
>
> So it is only slow on the slow port? If so it kind of sounds like the
> fs may be mounted sync and/or the disks write cache is disabled.
> smartctl --xall sometimes works against usb disk and
> sometimes it does not work. if it works it w
On any other filesystems I have used, using sync makes performance suck.
No idea about what is normal/ok for btrfs.
You might see if all btrfs filesystems are using sync or just the
removable ones are.
On Thu, Aug 15, 2024 at 5:21 PM Andre Robatino
wrote:
>
> The output of "smartctl --xall /dev
The output of "smartctl --xall /dev/sdb1" includes
SMART support is: Available - device has SMART capability.
SMART support is: Disabled
Temperature Warning: Disabled or Not Supported
query_cmd_support response too short
Read Cache is:Enabled
Writeback Cache is: Enabled
Interes
So it is only slow on the slow port? If so it kind of sounds like the
fs may be mounted sync and/or the disks write cache is disabled.
smartctl --xall sometimes works against usb disk and
sometimes it does not work. if it works it will tell you the write
cache status. The sync and/or btrfs fil
The drive is about 76% full but I don't think it's fragmentation since the
transfer of the same ~2 GB file to the portable drive is consistently
relatively fast from a blue or yellow USB port, and very slow from a black USB
port. Here's the output of "df -T /dev/sdb1" with the drive plugged in:
You might install usbview and run it. It will give you a gui window
and let you drill down and examine what each USB device looks like.
It would make me think it is some BTRFS issue. maybe for some reason
the disk is fragmented and having to write blocks all over the place.
The way I know to tes
The portable drive is a HDD, formatted with BTRFS (same as each of the three
F40 machines, the two desktops and the laptop). The desktops have HDDs and the
laptop has an SSD but they always have and the transfer speed used to be
faster, none of that hardware has changed. After noticing the slow
Is this a spinning disk or an SSD? And what are you writing to the
disk?And what filesystem is on the disk?
On Thu, Aug 15, 2024 at 12:23 PM Andre Robatino
wrote:
>
> Testing a little more, the transfer speed between the desktop's black USB
> ports and the portable drive is only slow (arou
Testing a little more, the transfer speed between the desktop's black USB ports
and the portable drive is only slow (around 2 MB/s) in one direction, from the
desktop to the portable drive. From the portable drive to the desktop, it's
about the same as before, around 25 MB/s. With the laptop's 3
I have a USB 3.0 portable drive which I've used for years with two desktops,
each with black USB 2.0 ports. I used to get roughly 25 MB/s transfer speed
which AIUI is roughly to be expected given that it's limited to USB 2. Lately,
the transfer speed is much slower, around 2 MB/s. I thought mayb
21 matches
Mail list logo
