Okay, I'm on fresh 13.10, just installed Liferea - slow performance and
high HDD disk usage during updating is back.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/290666
Title:
Liferea stalling, use
** Branch linked: lp:ubuntu/liferea
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/290666
Title:
Liferea stalling, uses excessive number of fsyncs
To manage notifications about this bug go to:
https
This bug was fixed in the package liferea - 1.8.3-0.1ubuntu1
---
liferea (1.8.3-0.1ubuntu1) precise; urgency=low
* New upstream release (LP: #290666, #371754, #741543, #716688)
* Merge from Debian unstable (LP: #935147), remaining changes:
* debian/patches:
- drop gtk-status
To spread the good news: Liferea 1.8.3 is our holy grail as it really
fixes this bug.
We already have it in Debian and what's left to close this bug is to
merge it to Ubuntu. If you like to help on that go to Bug #935147 and at
least state that it affects you.
For anyone who likes to experience t
After using the fsync disabled versions from my PPA for over two years
now on regular basis i finally managed to crash my database. As Adrian
pointed out in Comment #65 unplugging the power cord is quite effective
;)
All in all i think it still is a good tradeoff for personal use to run
without th
Liferea is still unbearably slow on Precise - 12.04. Using eatmydata
makes it usable, but this is not a solution.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/290666
Title:
Liferea stalling, uses e
Ahh, I just saw the eatmydata comment above. Didn't know about that
utility, so I'll withdraw this rather than duplicating efforts :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/290666
Title:
Lif
I've packaged up the fsync() and fsyncdata() functions above, written a
little wrapper which runs a command with it (such as liferea) and then
syncs ONCE when the application closes. Again, this is NOT the
solution, but a lot of people might find this useful until liferea /
sqlite is fixed.
https
Same here on Ubuntu Natty Beta 2, with Liferea 1.6.4. It is slow e.g. when you
mark multiple feeds as read.
Sorry, but for me it is unuseable in this state, I can't wait several
seconds/minutes to mark feeds as read.
To reproduce this behaviour just install liferea, run it from me menu,
wait un
Vadim, with "killing liferea process during feeds update" you are not
testing the problematic case - for that fsync is not required.
"unplug the power cable of your computer during feed update" is the
problematic case (or kernel crashes).
--
You received this bug notification because you are a m
I used patched version of liferea since it was uploaded, and I haven't
faced any serious issues even when killing liferea process during feeds
update. Definitely vote for "speed" over "persistence".
I totally understand why liferea developers don't want to remove fsyncs. But on
the other side is
Yes, slow as hell. One solution is to use:
eatmydata liferea
which works like a charm; but unfortunately if you start liferea from
the indicator menu (in unity), it won't use "eatmydata liferea" but only
"liferea" - and that's slow as hell.
--
You received this bug notification because you are
So what is the status for natty? I recently switched from a patched
version to the "original" natty version and OH BOY, what a PITA. Slow
as hell.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/290666
Apparently fixed upstream in the yet-unreleased 1.7.5. At least, I found
this in the changelog:
* Improve the UI responsiveness by using sqlite3async.
(patch by Wictor Lund)
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bu
Upstream doesn't like the patch. They prefer the fsyncs since that
provides database consistency. As said in my previous post, some work is
done in another direction, living with fsyncs.
If you don't want them and are ok with the consequences of disabling
fsync, you can apply the patch. Upstream w
I have forwarded the most recent patches upstream. If any other patches
are created, could you make sure that you inform the original developers
by posting the patch to their bug tracker too, otherwise the author of
the program may not see your patch. Thanks!
** Tags added: patch-forwarded-upstrea
This patch solves the problem. Users should be aware that disabling fsync
compromises durability (i.e. system crashes can corrupt your database).
The relevant liferea bug is
https://sourceforge.net/tracker/index.php?func=detail&aid=2216604&group_id=87005&atid=581684
I think there is some develop
Thanks, Ralf, incredibly much faster after uninstalling my old liferea and get
that version 1.7.4.
Installing...
liferea-data_1.7.4-2~llfsyncfix1_all.deb
liferea_1.7.4-2~llfsyncfix1_i386.deb
liferea-dbg_1.7.4-2~llfsyncfix1_i386.deb
...did the trick, now it works like a Ferrari :)
--
Liferea
Disabling barriers on my ext4 partition seems to help.
in /etc/fstab:
UUID=9b920777-5aca-40f8-afa5-631a04057401 / ext4
defaults,noatime,nodiratime,barrier=0 1 1
UUID=27941cae-e541-407e-9572-f0adc25ba175 /home ext4
defaults,noatime,nodiratime,barrier=0 1 2
I added "barrier=0" as option and reboo
> for EXT4 users: i repackaged 1.7.4 with the fsync fix for lucid
https://launchpad.net/~bojo42/+archive/liferea
This version is much faster on lucid (ext4)
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you
a few days of testing passed and the "vanilla" 1.7.4 from the unstable
PPA is mostly usable on stock lucid (amd64). but i noticed that on high
CPU load and low I/O (kernel compilation) the "vanilla" one gets
unresponsive and updating feeds gets really slow. in the same situation
the "hacked" build
At least yesterday, the performance in Lucid was still bad. I will post
the exact versions when I get back home.
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
On 13/04/10 10:22, bojo42 wrote:
> @Emilio: this time you got me ;) i haven't tested it without the hack as
> the changes doesn't seem that big. i did so now and result is much
> better as my HDD keeps playing cool while updating the feeds, but i am
> already on lucid and this probably a result of
@Emilio: this time you got me ;) i haven't tested it without the hack as
the changes doesn't seem that big. i did so now and result is much
better as my HDD keeps playing cool while updating the feeds, but i am
already on lucid and this probably a result of changes in linux 2.6.32
regarding EXT4. i
On 12/04/10 16:07, bojo42 wrote:
> for EXT4 users: i repackaged 1.7.4 with the fsync fix for lucid
> https://launchpad.net/~bojo42/+archive/liferea
People have reported that 1.7 works much better performance-wise. Do you still
need the hack with it? Have you tried without it?
--
Liferea stalling
for EXT4 users: i repackaged 1.7.4 with the fsync fix for lucid
https://launchpad.net/~bojo42/+archive/liferea
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
any news for Lucid Lynx?
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.
On 30/01/10 12:04, bojo42 wrote:
> @Emilio: sure i tried it before, but atleast on EXT4 and eCryptfs my HDD
> still makes those ugly sounds. could be a bit better than 1.7.2 but not
> really usable on my configuration. sry ;(
Oh right, we're still not good on ext4. On ext3 it should be much
better
@Emilio: sure i tried it before, but atleast on EXT4 and eCryptfs my HDD
still makes those ugly sounds. could be a bit better than 1.7.2 but not
really usable on my configuration. sry ;(
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this
On 30/01/10 11:21, bojo42 wrote:
> i redid the packaging of the fsync fix for version 1.7.3 and also created a
> seperate PPA for it:
> https://launchpad.net/~bojo42/+archive/liferea
1.7.3 should be a bit better performance-wise, can you try it without this hack
and see how it performs?
--
Lif
i redid the packaging of the fsync fix for version 1.7.3 and also created a
seperate PPA for it:
https://launchpad.net/~bojo42/+archive/liferea
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member
just for the record, in the workaround startup script the last line should be:
/usr/bin/liferea.real $*
otherwise parameters won't find there way to the binary and stuff like
liferea-add-feed won't work.
if fixed the package in my ppa accordingly:
https://launchpad.net/~bojo42/+archive/ppa/+sourc
I did some quick straces with karmic's 1.6.0-1ubuntu2 vs. 1.6.1 and
unstable 1.7.2 from the web site.
$ grep -c fdatasync *.txt
1.6.0-1ubuntu2.txt:1264
1.6.1.txt:1004
1.7.2.txt:996
$ grep -c fsync *.txt
1.6.0-1ubuntu2.txt:4
1.6.1.txt:3
1.7.2.txt:0
There is a slight downward trend, but most of th
Does anyone now if the current upstream version 1.6.1 shows the same
behaviour?
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs m
i took the workaround and integrated it into the latest packages from
the liferea unstable PPA. you can grab those packages here:
https://launchpad.net/~bojo42/+archive/ppa/+sourcepub/893166/+listing-
archive-extra
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bu
I'm a bit dismayed that karmic shipped with a completely broken version
of liferea. Is there any attempt to repair this?
Also, while the fix works for the first few minutes for me on the AMD64
version, it doesn't seem to last, and the system slows to a crawl again
by the second sync.
tarek : )
-
@perfectska04
Thank you very much. It worked great!
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lis
Agh, I'm probably still half asleep. I apologize, for step 4 you also need an
extra line at the beginning, here's what it should be:
!/bin/sh
export LD_PRELOAD=/usr/src/libfsync/libfsync.so
/usr/bin/liferea.real
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs
Sorry, for step 4, you should put the following in the Gedit window:
export LD_PRELOAD=/usr/src/libfsync/libfsync.so
/usr/bin/liferea.real
And then give the new file permissions to run by running the following in a
terminal:
sudo chmod +x /usr/bin/liferea
You might also need to add "sudo" to the
@Nicolás Schubert
Sure, I did as follows:
1. Enter the following in a terminal:
sudo mkdir /usr/src/libfsync
sudo gedit /usr/src/libfsync/libfsync.c
2. Copy the following inside the Gedit window that pops up and save+close
afterwards:
#include
int fsync(int i)
{
return 0;
}
int fdatasync(in
@perfectska04
Please, would you mind explaining, really noobish friendly, what you
did?
I tried to combine #32 and the fix explained in #12 with no success. But
I must admit that I probably made something wrong.
Thanks
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad
@Maykel Moya
Thanks! After combining your instructions with post #30 and post #14, Liferea
is now working as it should be. Globally updating feeds and "Mark all as read"
now work instantly even on my netbook, as opposed to waiting for minutes.
--
Liferea stalling, uses excessive number of fsync
@perfectska04
Just rename liferea to something else and call it through a script
# mv /usr/bin/liferea /usr/bin/liferea.real
# cat
The new liferea does not have an editable /usr/bin/liferea file, any
indications as to where I should add the last step for the workaround?
(adding "export LD_PRELOAD=/usr/src/libfsync/libfsync.so" to said file)
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/
Oh, this DID work. Put is the file I used in its entirety for
completeness:
#include
int fsync(int i)
{
return 0;
}
int fdatasync(int i)
{
return 0;
}
Probably stdio.h isn't necessary.. Finally, things are back to normal!
yay!
tarek : )
--
Liferea stalling, uses excessive nu
I tried #12 in unadulterated form in Karmic latest, and that didn't
worked.
I also tried modifying libfsync.so to:
int fdatasync (int fd) {
return 0;
}
and that didn't work either.
Any ideas?
tarek : )
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/2906
Tarek: I don't believe there is a need for more traces until a version
>1.6 comes out.
perfectska04: Karmic's sqlite has switched from fsync() to fdatasync().
You can either update the workaround in #12 according to #14 or try the
patch in #22.
--
Liferea stalling, uses excessive number of fsync
I've been having this issue as well, for the longest time.
In Jaunty, the workaround in post #12 worked perfectly, so I forgot
about the issue. In Karmic, however, that workaround is no longer
applicable.
The latest version is indeed much faster, but that doesn't mean much, as
it's still unusable
Oh, to add to this, it's in the latest Karmic with liferea version 1.6.0
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
Liferea still takes minutes to complete any feed update, and disables my
system in the interim. This has essentially made liferea unusable.
Do I need to do the traces as previous?
tarek : )
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received
* marmuta :
> Emilio, I do see quite an improvement as 1.6 is something in the
> ballpark of 40% faster for me. Ext4/fdatasync(?) help too as the rest of
> the system stays fairly responsive.
Same here. It IS definitely faster. Not really fast, but faster.
--
Liferea stalling, uses excessive num
marmuta wrote:
> Emilio, I do see quite an improvement as 1.6 is something in the
> ballpark of 40% faster for me. Ext4/fdatasync(?) help too as the rest of
> the system stays fairly responsive.
Good to hear :)
> Unfortunately it still means counting startup and feed update times in
> minutes on
Emilio, I do see quite an improvement as 1.6 is something in the
ballpark of 40% faster for me. Ext4/fdatasync(?) help too as the rest of
the system stays fairly responsive.
Unfortunately it still means counting startup and feed update times in
minutes on my setup. Have a look at the time stamps o
marmuta wrote:
> Here is an updated quilt patch for Karmic's current liferea
> 1.6.0~rc6-1ubuntu1.
Is it still as bad with 1.6.0? Performance fixes will come in 1.8, but I'm
interested to know if it's equally bad with 1.6 or anything has changed.
--
Liferea stalling, uses excessive number of fsy
Norman: Ultimately your patch is what I want too, but I felt it was more
benign to stick with whatever liferea developers intended as a default.
My hope is that this would allow Ubuntu devs/MOTUs to maybe, possibly,
some day pick it up and add it to the package without risk for
unaffected liferea u
Here is an updated quilt patch for Karmic's current liferea
1.6.0~rc6-1ubuntu1. Only line numbers changed, otherwise it applied
fine. Before there were ~1400 fdatasyncs with a fresh profile, after
none (assuming LIFEREA_SYNCHRONOUS set to 0).
** Attachment added: "pragma_synchronous_1.6.0~rc6"
I've created a slightly-modified version of marmuta's patch which
changes the default synchronization mode to 0 (no sync), rather than
preserving the existing default (2, full sync). Either patch will allow
you to use an environment variable to set a specific synchronization
mode, but by changing
My favorite solution of the day is now this patch for 1.4.26-0ubuntu1 that adds
an environment variable for the sqlite3 sync behaviour. Possible values are
0..3, with 0 for no sync. See
http://www.sqlite.org/pragma.html#pragma_synchronous.
Basically running liferea like this disables syncing:
Thanks for the PPA. Liferea-1.6.0-rc5 does a little better but it still
takes 15min for the update of the initial feeds. I've built it from
source too for good measure with the same result. I realize though that
my SSD is probably close to the worst case and HDs would fare better.
--
Liferea stal
Switching to liferea 1.6.0 from
https://launchpad.net/~liferea/+archive/ppa solved hang issues for me on
Ubuntu 9.04 (2.6.29 kernel from http://kernel.ubuntu.com/~kernel-
ppa/mainline/) and ext4.
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You recei
Disabling fsync() doesn't help anymore in Karmic because Sqlite3 seems
to have switched to fdatasync() by default. Disabling fdatasync does the
trick for me this time, liferea starts almost instantly again.
The hack in
https://bugs.launchpad.net/ubuntu/+source/liferea/+bug/333718/comments/10
wou
No improvement in Karmic ~Alpha2, liferea 1.4.26-0ubuntu1, sqlite3
3.6.14.2-1. Starting liferea took >30min until I finally lost patience
and killed it. That's with an empty ~/.liferea_1.4 folder and ext4 on a
(admittedly rather slowish) SSD.
Here is the output of (full output attached):
$ rm -rf
A temporary fix was posted here:
http://ubuntuforums.org/showthread.php?p=7162556#8
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bu
look https://bugs.launchpad.net/ubuntu/+source/liferea/+bug/333718
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
u
I can confirm that I am having this same issue.
Liferea: 1.4.26
Jaunty
Libsqlite 3.6.10
Laptop Specs: HP dv5242ea | Ubuntu 8.10 | Core Duo T2050 1.60GHz | 2048
MB RAM | 320GB SATA | DVD-RAM Matshita UJ 840S | nVidia G72M [GeForce Go
7400] 256mb | Intel PRO/Wireless 3945ABG
--
Liferea stalling,
Same problem for me!
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubun
marking this as "triaged" here, even though it's unclear what a possible
solution would be...
importance=high
** Changed in: liferea (Ubuntu)
Importance: Undecided => High
** Changed in: liferea (Ubuntu)
Status: New => Triaged
--
Liferea stalling, uses excessive number of fsyncs
http
Being unhappy with the increasing fsync frequency of applications in
general and misguided calls for even more fsyncs for ext4, I've finally
given up and disabled fsync() system wide. After all that time liferea
is now usable once again :)
--
Liferea stalling, uses excessive number of fsyncs
http
Same here on jaunty. liferea has become excessively slow, and stracing
it also pointed to excessive fsync calls.
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
Tried liferea again in Jaunty 64bit Alpha2, this time with reiserfs for
a change, but there is no improvement. Still unusably slow to start and
scores of fsyncs.
Meanwhile my upstream bug report has been closed without resolution.
http://sourceforge.net/support/tracker.php?aid=2216604
--
Liferea
Yes, this bug was a PITA with firefox 3.0. I've been running firefox profiles
in a ramdisk ever since.
How that relates to liferea, other than both using sqlite, I dont know. Liferea
calls sqlite functions on its own and as far as I could see not through
xulrunner. 'toolkit.storage.synchronous=0
This sounds like the known bug in xulrunner:
https://bugzilla.mozilla.org/show_bug.cgi?id=421482
The issue is unfixed AFAIK (long tread, hard to keep track of the status), but
one of the recommendations is to set preference 'toolkit.storage.synchronous'
to 0. This is DANGEROUS, as it could resu
** Bug watch added: SourceForge.net Tracker #2216604
http://sourceforge.net/support/tracker.php?aid=2216604
** Also affects: liferea via
http://sourceforge.net/support/tracker.php?aid=2216604
Importance: Unknown
Status: Unknown
--
Liferea stalling, uses excessive number of fsyncs
I've tried the current upstream stable version 1.4.21b with even worse
results. strace reports 1749 fsyncs on first startup and shutdown after
all feeds are initially loaded.
Unsuccessfully digging around for a workaround. I found that sqlite3 hard-codes
the "safety_level" to full-sync and lifere
strace -etrace=fsync -o liferea_session.strace liferea
** Attachment added: "liferea_session.strace"
http://launchpadlibrarian.net/18980299/liferea_session.strace
--
Liferea stalling, uses excessive number of fsyncs
https://bugs.launchpad.net/bugs/290666
You received this bug notification be
75 matches
Mail list logo
