[Bug 42104] New: EXT4 filesystem slows down WinRAR
https://bugs.winehq.org/show_bug.cgi?id=42104 Bug ID: 42104 Summary: EXT4 filesystem slows down WinRAR Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: k638540(a)mvrht.com Distribution: --- Hello. Instructions to reproduce the bug: 1) create any multivolume archive with WinRAR 5.40 (older versions are probably OK too), set volume/part size to 1GB or 2GB, full archive size 5-10GB, do not use compression, only store mode 2) in the end of creating each volume you'll see 3-5 seconds lag and info "calculating the checksum 99%", but all CPU cores are doing nothing at this moment 3) bug is not present on tmpfs (ramdisk), not present on NTFS (Windows 7 @ virtualbox) All tests were perfmormed on Ubuntu 14, 3GHz 8 cores CPU, normal HDD. I tried editing etc/fstab, I tried to add "noatime", but it didn't change anything. In practice, when you create 100GB archive splitted into 1GB parts, entire operation is finished 10 minutes later thanks to this 3-5 seconds delay for each part. I hope somebody can fix this. Thank you. PS. Wine version doesn't matter. I tested pretty much everything what's available (1.4 1.5 1.6 1.8 2.0 beta). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 --- Comment #1 from Bruno Jesus <00cpxxx(a)gmail.com> --- Is the problem also present in ext3 or reiserfs? I'm not skilled into disk caching or related subjects but how can you tell this is a Wine problem? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 --- Comment #2 from AshleyJade <k638540(a)mvrht.com> --- Well, make your own simple tests. Before writing this I asked a friend to make splitted archive on his Ubuntu and he confirmed this. Calculating checksum lasts about 5 seconds. Normally there is no delay at all (only a small fraction). I can't test other linux filesystems, because it is a dedicated server and I am not admin there. :) Also, native rar for linux, exactly same version 5.40, exactly same parameters to make archive - no lag on EXT4. Only WinRAR has lag. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 --- Comment #3 from AshleyJade <k638540(a)mvrht.com> --- I've managed to create new NTFS and EXT3 partitions on Ubuntu Server 14 LTS. As I predicted - there is no delay while "calculating the checksum" at all. Only EXT4 filesystem makes problem. Of course I am not demanding any changes from Linux team in EXT4 code, this is clearly Wine's problem, Wine's relationship with EXT4 and WinRAR. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal Version|unspecified |2.0-rc3 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com --- Comment #4 from Austin English <austinenglish(a)gmail.com> --- (In reply to AshleyJade from comment #3)
Of course I am not demanding any changes from Linux team in EXT4 code, this is clearly Wine's problem, Wine's relationship with EXT4 and WinRAR.
How is that clear? Wine doesn't distinguish between ext3 and ext4, so I'm curious how you've determined Wine is at fault rather than the kernel. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 --- Comment #5 from AshleyJade <k638540(a)mvrht.com> --- I am not Linux nor Wine expert. Everything is based on the simple tests I made. By "kernel" what do you mean? Ubuntu 14 LTS is guilty here in your opinion? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- (In reply to AshleyJade from comment #5)
I am not Linux nor Wine expert. Everything is based on the simple tests I made. By "kernel" what do you mean? Ubuntu 14 LTS is guilty here in your opinion?
I mean the Linux kernel, in which case you should file a Ubuntu bug and provide them a link to this bug. It could end up being a wine bug, but at this point it looks more like a kernel bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42104 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #8 from Austin English <austinenglish(a)gmail.com> --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream. Setting back to RESOLVED NOTOURBUG. Sorry for the spam. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org