I have just installed the latest version of Fedora Gnome on my HP laptop. I had to import a 50 GB OVA file from my USB HDD to my hard drive via USB 3.0.
When the copying was taking place through VirtualBox, the system hung almost completely, I was not able to even move my mouse.
Why does this happen ?
Reading this: https://askubuntu.com/q/397249/628460
It seems to be the case for Debian based OSes, but then why is it happening in Fedora ?
I just formatted from Windows 10, and while I hate a lot of things about it, it never made the system unusable during heavy I/O operations. I had multiple tabs in Chrome open without any lag whatsoever.
I say this, not to criticize Fedora but to point out this should be the case in modern OSes. So why am I facing this issue?
Let me know what you think and if any further information is needed.
Thanks.
On Wed, 1 Apr 2020 04:39:13 +0530 Sreyan Chakravarty wrote:
Why does this happen ?
I don't know why, but I've noticed it as well. It wasn't always this way, but a few fedora versions ago it changed. I always figured some kernel developer got a bee in his bonnet about some disk copying benchmark and sacrificed everything else to make his pet benchmark run faster.
Marvelous.
So now what do we do ?
On Wed, Apr 1, 2020 at 4:54 AM Tom Horsley horsley1953@gmail.com wrote:
On Wed, 1 Apr 2020 04:39:13 +0530 Sreyan Chakravarty wrote:
Why does this happen ?
I don't know why, but I've noticed it as well. It wasn't always this way, but a few fedora versions ago it changed. I always figured some kernel developer got a bee in his bonnet about some disk copying benchmark and sacrificed everything else to make his pet benchmark run faster. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Wed, 1 Apr 2020 04:55:23 +0530 Sreyan Chakravarty wrote:
Marvelous.
So now what do we do ?
Well, the ubuntu bug had suggested sysctl settings, but I've mostly ignored it since I don't have to copy big files that often, so I don't know how well the ubuntu suggestions work.
These are what I set: vm.dirty_background_bytes = 3000000 vm.dirty_bytes = 5000000
That limits the to-be-written bytes to 50Mb, and when it hits 50MB it will clear the write cache down to 30MB and let writes happen again. Since 20MB of writes happens pretty fast on modern HD's this makes response reasonable. If these 2 values are 0 then these 2 rule: vm.dirty_background_ratio = 0 vm.dirty_ratio = 0 You might note what the default is, all my system have it overridden.
They are in %'s of memory which on a 4GB machine means 40MB is 1%. I am not sure what the default spread but at 5% spread that is 200MB and will take a while to write, and it may be defaulted to a 5% spread.
Outside of benchmarks having a huge writecache is not that useful, and causes issues like this and really you don't need a very big write cache at all to make the io subsystem work right. See how things go with those numbers and then play around with reducing the spread as the smaller the spreads the more often the pauses are, but that faster the finish and at 20MB spread I typically cannot noticed the pause.
On Tue, Mar 31, 2020 at 6:40 PM Tom Horsley horsley1953@gmail.com wrote:
On Wed, 1 Apr 2020 04:55:23 +0530 Sreyan Chakravarty wrote:
Marvelous.
So now what do we do ?
Well, the ubuntu bug had suggested sysctl settings, but I've mostly ignored it since I don't have to copy big files that often, so I don't know how well the ubuntu suggestions work. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 3/31/20 5:00 PM, Roger Heflin wrote:
These are what I set: vm.dirty_background_bytes = 3000000 vm.dirty_bytes = 5000000
I think you're missing a zero. If those are your actual numbers, you have a very small buffer. Even with your numbers that seems a little small. I have noticed that copy big files especially over USB bogs the system pretty badly. I'll try modifying my settings to see if it helps.
That limits the to-be-written bytes to 50Mb, and when it hits 50MB it will clear the write cache down to 30MB and let writes happen again. Since 20MB of writes happens pretty fast on modern HD's this makes response reasonable. If these 2 values are 0 then these 2 rule: vm.dirty_background_ratio = 0 vm.dirty_ratio = 0
You can only set one or the other. Setting the bytes resets the ratio and vice versa.
You might note what the default is, all my system have it overridden.
/proc/sys/vm/dirty_background_ratio: 10 /proc/sys/vm/dirty_ratio: 20
Here's the info on those settings from the kernel doc: https://www.kernel.org/doc/Documentation/sysctl/vm.txt ==============================================================
dirty_background_bytes
Contains the amount of dirty memory at which the background kernel flusher threads will start writeback.
Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only one of them may be specified at a time. When one sysctl is written it is immediately taken into account to evaluate the dirty memory limits and the other appears as 0 when read.
==============================================================
dirty_background_ratio
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which the background kernel flusher threads will start writing out dirty data.
The total available memory is not equal to total system memory.
==============================================================
dirty_bytes
Contains the amount of dirty memory at which a process generating disk writes will itself start writeback.
Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be specified at a time. When one sysctl is written it is immediately taken into account to evaluate the dirty memory limits and the other appears as 0 when read.
Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any value lower than this limit will be ignored and the old configuration will be retained.
==============================================================
dirty_ratio
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
The total available memory is not equal to total system memory.
==============================================================
Mine aren't missing a 0, I divided wrong and added a 0, so I am using 5MB and 3MB, which would leave my spread at 2MB or at say 100MB/sec 1/50sec. It has been a long time since I set them and my system works decent during copying.
On Tue, Mar 31, 2020 at 7:22 PM Samuel Sieb samuel@sieb.net wrote:
On 3/31/20 5:00 PM, Roger Heflin wrote:
These are what I set: vm.dirty_background_bytes = 3000000 vm.dirty_bytes = 5000000
I think you're missing a zero. If those are your actual numbers, you have a very small buffer. Even with your numbers that seems a little small. I have noticed that copy big files especially over USB bogs the system pretty badly. I'll try modifying my settings to see if it helps.
That limits the to-be-written bytes to 50Mb, and when it hits 50MB it will clear the write cache down to 30MB and let writes happen again. Since 20MB of writes happens pretty fast on modern HD's this makes response reasonable. If these 2 values are 0 then these 2 rule: vm.dirty_background_ratio = 0 vm.dirty_ratio = 0
You can only set one or the other. Setting the bytes resets the ratio and vice versa.
You might note what the default is, all my system have it overridden.
/proc/sys/vm/dirty_background_ratio: 10 /proc/sys/vm/dirty_ratio: 20
Here's the info on those settings from the kernel doc: https://www.kernel.org/doc/Documentation/sysctl/vm.txt ==============================================================
dirty_background_bytes
Contains the amount of dirty memory at which the background kernel flusher threads will start writeback.
Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only one of them may be specified at a time. When one sysctl is written it is immediately taken into account to evaluate the dirty memory limits and the other appears as 0 when read.
==============================================================
dirty_background_ratio
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which the background kernel flusher threads will start writing out dirty data.
The total available memory is not equal to total system memory.
==============================================================
dirty_bytes
Contains the amount of dirty memory at which a process generating disk writes will itself start writeback.
Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be specified at a time. When one sysctl is written it is immediately taken into account to evaluate the dirty memory limits and the other appears as 0 when read.
Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any value lower than this limit will be ignored and the old configuration will be retained.
==============================================================
dirty_ratio
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
The total available memory is not equal to total system memory.
============================================================== _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
This may not solve the problem but if you need it to work right now, what would happen if your reniced it?
On Tue, Mar 31, 2020 at 7:40 PM Tom Horsley horsley1953@gmail.com wrote:
On Wed, 1 Apr 2020 04:55:23 +0530 Sreyan Chakravarty wrote:
Marvelous.
So now what do we do ?
Well, the ubuntu bug had suggested sysctl settings, but I've mostly ignored it since I don't have to copy big files that often, so I don't know how well the ubuntu suggestions work. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 3/31/20 5:01 PM, Mauricio Tavares wrote:
This may not solve the problem but if you need it to work rightnow, what would happen if your reniced it?
That doesn't help. There's no lack of CPU time and I don't think process priority has any effect on IO priority.
I have never seen nice have any useful IO throttling effect (unless you are using 100% of your cpu with non-niced processes that is), so for exactly the reason you say, it takes very little cpu to do a massive amount of IO, so nice won't work.
There are some kernel knobs that will control IO but those knobs are not very simple (see cgroups), so it is easier to just use the dirty, and a secondary effect to the dirty is that at 20%, the writecache can also cause the system to page to get that 20% memory.
On Tue, Mar 31, 2020 at 7:28 PM Samuel Sieb samuel@sieb.net wrote:
On 3/31/20 5:01 PM, Mauricio Tavares wrote:
This may not solve the problem but if you need it to work rightnow, what would happen if your reniced it?
That doesn't help. There's no lack of CPU time and I don't think process priority has any effect on IO priority. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Tue, 31 Mar 2020 19:23:53 -0400 Tom Horsley horsley1953@gmail.com wrote:
On Wed, 1 Apr 2020 04:39:13 +0530 Sreyan Chakravarty wrote:
Why does this happen ?
I don't know why, but I've noticed it as well. It wasn't always this way, but a few fedora versions ago it changed.
A few versions ago the default disk drivers shifted to multi queue versions from single queue. I don't know that this had any thing to do with it, but it is a change in disk handling.
I don't copy large files, so I haven't seen any issues. I'm using the bfq driver, but there is still a version of the deadline driver that I haven't tried. Perhaps you could switch which driver you are using to see if it helps.
On Tue, 31 Mar 2020 19:23:53 -0400 Tom Horsley <horsley1953(a)gmail.com> wrote:
A few versions ago the default disk drivers shifted to multi queue versions from single queue. I don't know that this had any thing to do with it, but it is a change in disk handling.
I don't copy large files, so I haven't seen any issues. I'm using the bfq driver, but there is still a version of the deadline driver that I haven't tried. Perhaps you could switch which driver you are using to see if it helps.
Can you please explain what the bfq driver is ? Are you using a HDD and not a SSD.
On Wed, 01 Apr 2020 06:02:07 -0000 "Sreyan Chakravarty" sreyan32@gmail.com wrote:
Can you please explain what the bfq driver is ? Are you using a HDD and not a SSD.
Budget Fair Queueing (BFQ) Storage-I/O Scheduler
kernel documentation https://www.kernel.org/doc/html/latest/block/bfq-iosched.html
some other sites
https://algo.ing.unimo.it/people/paolo/disk_sched/
Yes, hdd, but bfq is designed to work with both. At the bottom of the last link there are links to performance tests for hdd and ssd.
Thank you.
On Thu, Apr 2, 2020 at 12:44 AM stan via users < users@lists.fedoraproject.org> wrote:
On Wed, 01 Apr 2020 06:02:07 -0000 "Sreyan Chakravarty" sreyan32@gmail.com wrote:
Can you please explain what the bfq driver is ? Are you using a HDD and not a SSD.
Budget Fair Queueing (BFQ) Storage-I/O Scheduler
kernel documentation https://www.kernel.org/doc/html/latest/block/bfq-iosched.html
some other sites
https://algo.ing.unimo.it/people/paolo/disk_sched/
Yes, hdd, but bfq is designed to work with both. At the bottom of the last link there are links to performance tests for hdd and ssd. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-04-01 07:09, Sreyan Chakravarty wrote:
I have just installed the latest version of Fedora Gnome on my HP laptop. I had to import a 50 GB OVA file from my USB HDD to my hard drive via USB 3.0.
I don't often copy large files to/from USB. But figured I give it a go. I created a file of about 57GB with random data.
I then used cp to copy the file to/from a USB 3.0 SanDisk Extreme Go PRO.
No noticeable slowdown.
I suspect the only difference is that I use only SSD.
On 3/31/20 5:42 PM, Ed Greshko wrote:
On 2020-04-01 07:09, Sreyan Chakravarty wrote:
I have just installed the latest version of Fedora Gnome on my HP laptop. I had to import a 50 GB OVA file from my USB HDD to my hard drive via USB 3.0.
I don't often copy large files to/from USB. But figured I give it a go. I created a file of about 57GB with random data.
I then used cp to copy the file to/from a USB 3.0 SanDisk Extreme Go PRO.
No noticeable slowdown.
I suspect the only difference is that I use only SSD.
Right. USB 3 and SSD is not going to be a good demonstration. Try a USB 2 drive to see what happens.
On 2020-04-01 08:46, Samuel Sieb wrote:
On 3/31/20 5:42 PM, Ed Greshko wrote:
On 2020-04-01 07:09, Sreyan Chakravarty wrote:
I have just installed the latest version of Fedora Gnome on my HP laptop. I had to import a 50 GB OVA file from my USB HDD to my hard drive via USB 3.0.
I don't often copy large files to/from USB. But figured I give it a go. I created a file of about 57GB with random data.
I then used cp to copy the file to/from a USB 3.0 SanDisk Extreme Go PRO.
No noticeable slowdown.
I suspect the only difference is that I use only SSD.
Right. USB 3 and SSD is not going to be a good demonstration. Try a USB 2 drive to see what happens.
I actually did use USB 2.0 first and switched to my recently added USB 3.0 port to match the OP.
Even with USB 2.0 there was no slowdown or stability issues. The transfer just took longer.
To have the issue it helps to have the reading disk be a quite a bit faster than the receiving disk that way the reading disk can easily get ahead and fill up the write cache faster than the reading disk can process it (it backs up into the writecache).
So USB3.0 3.5-7200rpm or an SSD will easily overrun a standard laptop 5900 rpm 2.5" hard disk.
On Tue, Mar 31, 2020 at 7:51 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 08:46, Samuel Sieb wrote:
On 3/31/20 5:42 PM, Ed Greshko wrote:
On 2020-04-01 07:09, Sreyan Chakravarty wrote:
I have just installed the latest version of Fedora Gnome on my HP laptop. I had to import a 50 GB OVA file from my USB HDD to my hard drive via USB 3.0.
I don't often copy large files to/from USB. But figured I give it a go. I created a file of about 57GB with random data.
I then used cp to copy the file to/from a USB 3.0 SanDisk Extreme Go PRO.
No noticeable slowdown.
I suspect the only difference is that I use only SSD.
Right. USB 3 and SSD is not going to be a good demonstration. Try a USB 2 drive to see what happens.
I actually did use USB 2.0 first and switched to my recently added USB 3.0 port to match the OP.
Even with USB 2.0 there was no slowdown or stability issues. The transfer just took longer.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-04-01 09:14, Roger Heflin wrote:
To have the issue it helps to have the reading disk be a quite a bit faster than the receiving disk that way the reading disk can easily get ahead and fill up the write cache faster than the reading disk can process it (it backs up into the writecache).
So USB3.0 3.5-7200rpm or an SSD will easily overrun a standard laptop 5900 rpm 2.5" hard disk.
This was not done on a quiet system CPU wise, boinc jobs running. But not much other I/O going on.
SDD--->USB-Flash
real 16m38.608s user 0m1.416s sys 3m37.379s
USB-Flash--->SDD
real 6m37.671s user 0m0.662s sys 1m4.984s
I then found an old laptop HDD in a USB 2.0 enclosure. Reading from the SDD should be much faster than writing to the HDD.
SDD--->HDD
real 30m53.407s user 0m0.942s sys 2m46.756s
HDD--->SDD
real 32m48.615s user 0m0.896s sys 1m9.483s
And, for completeness
SDD--->SDD
real 4m58.406s user 0m0.517s sys 1m8.402s
No issues at anytime with stability or slowdown in all cases.
Try : USB -> HDD.
Please dont use an SSD.
You are not testing correctly.
On Wed, Apr 1, 2020 at 8:56 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 09:14, Roger Heflin wrote:
To have the issue it helps to have the reading disk be a quite a bit faster than the receiving disk that way the reading disk can easily get ahead and fill up the write cache faster than the reading disk can process it (it backs up into the writecache).
So USB3.0 3.5-7200rpm or an SSD will easily overrun a standard laptop 5900 rpm 2.5" hard disk.
This was not done on a quiet system CPU wise, boinc jobs running. But not much other I/O going on.
SDD--->USB-Flash
real 16m38.608s user 0m1.416s sys 3m37.379s
USB-Flash--->SDD
real 6m37.671s user 0m0.662s sys 1m4.984s
I then found an old laptop HDD in a USB 2.0 enclosure. Reading from the SDD should be much faster than writing to the HDD.
SDD--->HDD
real 30m53.407s user 0m0.942s sys 2m46.756s
HDD--->SDD
real 32m48.615s user 0m0.896s sys 1m9.483s
And, for completeness
SDD--->SDD
real 4m58.406s user 0m0.517s sys 1m8.402s
No issues at anytime with stability or slowdown in all cases.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-04-01 13:58, Sreyan Chakravarty wrote:
Try : USB -> HDD.
Well, as I said, the HDD is "an old laptop HDD in a USB 2.0 enclosure".
So, I would be doing USB-Flash--->USB HDD.
Is that what you would be interested in?
No, you are missing the point. The kernel needs to be on HDD, or rather the cache used by the kernel needs to be on the HDD.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default now ?
Because thats what I am reading here: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
On Wed, Apr 1, 2020 at 12:40 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 13:58, Sreyan Chakravarty wrote:
Try : USB -> HDD.
Well, as I said, the HDD is "an old laptop HDD in a USB 2.0 enclosure".
So, I would be doing USB-Flash--->USB HDD.
Is that what you would be interested in?
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-04-01 15:49, Sreyan Chakravarty wrote:
No, you are missing the point. The kernel needs to be on HDD, or rather the cache used by the kernel needs to be on the HDD.
I don't think it is I missing the point. I already informed you of my system's configuration. So, I found it odd you'd be asking me for the additional test. Thus, my query to you.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default now ?
Because thats what I am reading here: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
Well, https://bugzilla.redhat.com/show_bug.cgi?id=1738828
Would appear to verify that.
I have some good news.
The workaround :
vm.dirty_background_bytes = 3000000 vm.dirty_bytes = 5000000
worked wonders for me.
I can now copy and watch YouTube at the same time.
Thank you and hoped this is fixed in upstream soon.
On Wed, Apr 1, 2020 at 1:30 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 15:49, Sreyan Chakravarty wrote:
No, you are missing the point. The kernel needs to be on HDD, or rather
the cache used by the kernel needs to be on the HDD.
I don't think it is I missing the point. I already informed you of my system's configuration. So, I found it odd you'd be asking me for the additional test. Thus, my query to you.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default
now ?
Because thats what I am reading here:
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
Well, https://bugzilla.redhat.com/show_bug.cgi?id=1738828
Would appear to verify that.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
I doubt this is going to be fixed upstream. This feature was put into the kernel sometime prior to 2004, and the first version was set even higher than 20%. And this becomes less of an issue if you have enough ram that you can give up the 20% of ram.
On Wed, Apr 1, 2020 at 3:56 AM Sreyan Chakravarty sreyan32@gmail.com wrote:
I have some good news.
The workaround :
vm.dirty_background_bytes = 3000000 vm.dirty_bytes = 5000000
worked wonders for me.
I can now copy and watch YouTube at the same time.
Thank you and hoped this is fixed in upstream soon.
On Wed, Apr 1, 2020 at 1:30 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 15:49, Sreyan Chakravarty wrote:
No, you are missing the point. The kernel needs to be on HDD, or rather the cache used by the kernel needs to be on the HDD.
I don't think it is I missing the point. I already informed you of my system's configuration. So, I found it odd you'd be asking me for the additional test. Thus, my query to you.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default now ?
Because thats what I am reading here: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
Well, https://bugzilla.redhat.com/show_bug.cgi?id=1738828
Would appear to verify that.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-- Regards, Sreyan Chakravarty _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
the "cache" is in memory. My original reason for setting it was I did usbstick and usb-sd cards, and both of those are really slow, and i also did not have a lot of ram in those laptops such that an additional 20% of memory going for writecache also made the system page horribly.
Ed: How much ram does your laptop have? At lot of should go away if you have extra ram and can afford for 20% of the ram to be used as writecache and still have enough ram such that you still aren't having to page/swap.
On Wed, Apr 1, 2020 at 2:50 AM Sreyan Chakravarty sreyan32@gmail.com wrote:
No, you are missing the point. The kernel needs to be on HDD, or rather the cache used by the kernel needs to be on the HDD.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default now ?
Because thats what I am reading here: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
On Wed, Apr 1, 2020 at 12:40 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 13:58, Sreyan Chakravarty wrote:
Try : USB -> HDD.
Well, as I said, the HDD is "an old laptop HDD in a USB 2.0 enclosure".
So, I would be doing USB-Flash--->USB HDD.
Is that what you would be interested in?
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-- Regards, Sreyan Chakravarty _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-04-01 20:50, Roger Heflin wrote:
the "cache" is in memory. My original reason for setting it was I did usbstick and usb-sd cards, and both of those are really slow, and i also did not have a lot of ram in those laptops such that an additional 20% of memory going for writecache also made the system page horribly.
Ed: How much ram does your laptop have? At lot of should go away if you have extra ram and can afford for 20% of the ram to be used as writecache and still have enough ram such that you still aren't having to page/swap.
The HDD referenced below came from a laptop.
The tower system I ran the transfers on, without any issues or kernel tweeks, has 8GB.
On Wed, Apr 1, 2020 at 2:50 AM Sreyan Chakravarty sreyan32@gmail.com wrote:
No, you are missing the point. The kernel needs to be on HDD, or rather the cache used by the kernel needs to be on the HDD.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default now ?
Because thats what I am reading here: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
On Wed, Apr 1, 2020 at 12:40 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 13:58, Sreyan Chakravarty wrote:
Try : USB -> HDD.
Well, as I said, the HDD is "an old laptop HDD in a USB 2.0 enclosure".
So, I would be doing USB-Flash--->USB HDD.
Is that what you would be interested in?
-- The key to getting good answers is to ask good questions.
-- Regards, Sreyan Chakravarty
It worked without any tweaks on my side too, once I updated Fedora 31 to the latest kernel that is 5.5, I was using 5.3.
On Wed, Apr 1, 2020 at 6:27 PM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-04-01 20:50, Roger Heflin wrote:
the "cache" is in memory. My original reason for setting it was I did usbstick and usb-sd cards, and both of those are really slow, and i also did not have a lot of ram in those laptops such that an additional 20% of memory going for writecache also made the system page horribly.
Ed: How much ram does your laptop have? At lot of should go away if you have extra ram and can afford for 20% of the ram to be used as writecache and still have enough ram such that you still aren't having to page/swap.
The HDD referenced below came from a laptop.
The tower system I ran the transfers on, without any issues or kernel tweeks, has 8GB.
On Wed, Apr 1, 2020 at 2:50 AM Sreyan Chakravarty sreyan32@gmail.com
wrote:
No, you are missing the point. The kernel needs to be on HDD, or rather
the cache used by the kernel needs to be on the HDD.
Anyways, can you tell me if Fedora 31 uses the BFQ scheduler by default
now ?
Because thats what I am reading here:
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-...
On Wed, Apr 1, 2020 at 12:40 PM Ed Greshko ed.greshko@greshko.com
wrote:
On 2020-04-01 13:58, Sreyan Chakravarty wrote:
Try : USB -> HDD.
Well, as I said, the HDD is "an old laptop HDD in a USB 2.0 enclosure".
So, I would be doing USB-Flash--->USB HDD.
Is that what you would be interested in?
-- The key to getting good answers is to ask good questions.
-- Regards, Sreyan Chakravarty
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-
Ed Greshko -
Mauricio Tavares -
Roger Heflin -
Samuel Sieb -
Sreyan Chakravarty -
stan -
Tom Horsley