Bug#648489: ITP: nuitka -- Nuitka is a fully compatible Python compiler, capable of accelerating the execution.
Package: wnpp Severity: wishlist Owner: Kay Hayen * Package name: nuitka Version : 0.3.15 Upstream Author : Name * URL : http://nuitka.net/ * License : GPLv3, uses BSD parts. Programming Lang: Python, C++, Assembler Description : Nuitka is a fully compatible Python compiler, capable of accelerating the execution.# Nuitka is a good replacement for the Python interpreter and compiles every construct that CPython 2.6 and 2.7 offer. It translates the Python into a C++ program that then uses “libpython” to execute in the same way as CPython does, in a very compatible way. The speed improvement is currently not very high, but the plan is to become very compatible first, and then to optimize for speed through compile time type inference. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012082528.22865.61135.report...@anna.home
Bug#648536: general: NTFS formatted external hard disk crashes Linux/Debian Wheezy
Package: general Severity: important Dear Maintainer, I use Debian Wheezy (Testing) with the current updates. I also use an external hard disk which is formatted with NTFS. The problem is that Linux/Debian crashes after I unmound this hard disk. After unmounting this hard disk my display gets black and there are many white letters. thank you -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012171353.3021.1441.reportbug@noname
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
Am 10.11.2011 10:42, schrieb Dmitry Smirnov: > Package: wnpp > Severity: wishlist > Owner: Dmitry Smirnov > > * Package name: r8168-dkms > Version : 8.026.00 > Upstream Author : Realtek Semiconductor Corp. > * URL : > http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false > * License : GPL-2+ (contains binary blobs) > Programming Lang: C > Description : Realtek r8168 device driver for Linux (DKMS version) > r8168 is the Linux device driver released for RealTek RTL8168B/8111B, > RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, RTL8168DP/8111DP, and > RTL8168E/8111E Gigabit Ethernet controllers with PCI-Express interface. > . > This is to substitute built-in r8169 driver if it doesn't work well. I just searched this thread in my MUA and notified that Andreas Beckmann already filled an ITP on 20.09.2011 @ #642198 @Andreas and Dmitry: You may cooperate on packaging or decide, who wants to maintain it in the future. @Ben: I still think this driver should be added as alternative driver to the archive, until r8169 will do its job for the promoted PCIIDs correctly. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Want to become a DM and co-maintainer
Hi, Where/how to apply to become a co-maintainer and a maintainer? The packages I'm interested into start with are: gnuradio and octave. Additionally, I have not found any package for USRP yet. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1321127664.6311.24.camel@x60
Re: Want to become a DM and co-maintainer
On Sat, Nov 12, 2011 at 08:54:24PM +0100, Svante Signell wrote: > Where/how to apply to become a co-maintainer and a maintainer? The > packages I'm interested into start with are: gnuradio and octave. Octave is group-maintained, the group's list is at http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2011-November/thread.html If you want to join, create an account on alioth and request to join the group. The above is a bit terse, so feel free to ask me if you need further information. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012204340.GA3502@t61
/tmp as tmpfs and consequence for imaging software
Hello, Recently debian put /tmp under tmpfs. Even if it increase reponsivness under desktop, it ruin completly sciene and imaging software that do some off loading on /tmp. For instance using gscan2pdf on 60pages document create more than 1.2G of image file under /tmp and crash du to missing space. What are the solution for this kind of problem ? Thanks Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazzy-mboxaez2yhtooq+juu0hpjc_8ab0qd4vgego1...@mail.gmail.com
Re: /tmp as tmpfs and consequence for imaging software
On Sat, Nov 12, 2011 at 10:24:00PM +0100, Bastien ROUCARIES wrote: > Hello, > > Recently debian put /tmp under tmpfs. > > Even if it increase reponsivness under desktop, it ruin completly > sciene and imaging software that do some off loading on /tmp. > > For instance using gscan2pdf on 60pages document create more than 1.2G > of image file under /tmp and crash du to missing space. > > What are the solution for this kind of problem ? You need to increase the swap size by the amount you'd use for /tmp. Or, if you have plenty of RAM, merely increase the cap but then it may have no place to be swapped to if you'd want the RAM for other uses. Which raises a question what is a reasonable /tmp size. I doubt a system where someone even considers scanning a 1.2G document would be so tight to not afford 2.4G of RAM+swap (the /tmp cap is still set to 50%, right?). Thus, this suggests it might be a good idea to adjust d-i defaults. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: /tmp as tmpfs and consequence for imaging software
Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : > You need to increase the swap size by the amount you'd use for /tmp. Well, the idea of such case is precisely to *not* use swap, but real disks. Such software already know how to manage its memory and disk-backed memory (thusly stored in /tmp) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012221236.gt4...@type.famille.thibault.fr
Re: /tmp as tmpfs and consequence for imaging software
Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit : > Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : > > You need to increase the swap size by the amount you'd use for /tmp. > > Well, the idea of such case is precisely to *not* use swap, but real > disks. Such software already know how to manage its memory and > disk-backed memory (thusly stored in /tmp) Practically speaking, the only significant difference is that files are not forced to disk as early. Otherwise, if you have a large enough swap, pages of a file on a tmpfs that are not used enough will be swapped. And pages of a file on a regular filesystem that are used enough will be kept in the buffer cache. OTOH, for a wide range of applications that do a lot of small writes, using tmpfs is a huge gain. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Bug#648536: marked as done (general: NTFS formatted external hard disk crashes Linux/Debian Wheezy)
Your message dated Sat, 12 Nov 2011 22:31:13 + with message-id <1321137073.18929.212.camel@deadeye> and subject line Re: Bug#648536: general: NTFS formatted external hard disk crashes Linux/Debian Wheezy has caused the Debian Bug report #648536, regarding general: NTFS formatted external hard disk crashes Linux/Debian Wheezy to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 648536: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648536 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: important Dear Maintainer, I use Debian Wheezy (Testing) with the current updates. I also use an external hard disk which is formatted with NTFS. The problem is that Linux/Debian crashes after I unmound this hard disk. After unmounting this hard disk my display gets black and there are many white letters. thank you -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On Sat, 2011-11-12 at 18:13 +0100, a_debian_user wrote: > Package: general > Severity: important > > Dear Maintainer, > > I use Debian Wheezy (Testing) with the current updates. > I also use an external hard disk which is formatted with NTFS. > > The problem is that Linux/Debian crashes after I unmound this hard disk. > After unmounting this hard disk my display gets black and there are many white > letters. This is probably the same as bug #631187, fixed in unstable. If you can reproduce this with linux-image-3.0.0-1-686-pae version 3.0.0-6 then open a new bug against that package (not general). Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part --- End Message ---
Re: /tmp as tmpfs and consequence for imaging software
On Sat, 2011-11-12 at 22:24 +0100, Bastien ROUCARIES wrote: > Hello, > > Recently debian put /tmp under tmpfs. > > Even if it increase reponsivness under desktop, it ruin completly > sciene and imaging software that do some off loading on /tmp. > > For instance using gscan2pdf on 60pages document create more than 1.2G > of image file under /tmp and crash du to missing space. > > What are the solution for this kind of problem ? This problem has little to do with use of tmpfs; it is not reasonable to assume that /tmp has that much space. Programs should generally allow use of /tmp to be overridden by $TMPDIR and should handle disk-full errors gracefully. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Re: /tmp as tmpfs and consequence for imaging software
On Sat, 12 Nov 2011, Bastien ROUCARIES wrote: Hello, Recently debian put /tmp under tmpfs. Even if it increase reponsivness under desktop, it ruin completly sciene and imaging software that do some off loading on /tmp. For instance using gscan2pdf on 60pages document create more than 1.2G of image file under /tmp and crash du to missing space. What are the solution for this kind of problem ? Can you make this software use /var/tmp instead of /tmp, and would that address your issue? There's some discussion about /var/tmp vs. /tmp, as part of a larger discussion on /tmp as tmpfs, in http://bugs.debian.org/630615 . -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.121728460.28...@tyger.mit.edu
Re: /tmp as tmpfs and consequence for imaging software
On Sat, Nov 12, 2011 at 10:24:00PM +0100, Bastien ROUCARIES wrote: > Recently debian put /tmp under tmpfs. > > Even if it increase reponsivness under desktop, it ruin completly > sciene and imaging software that do some off loading on /tmp. > > For instance using gscan2pdf on 60pages document create more than 1.2G > of image file under /tmp and crash du to missing space. > > What are the solution for this kind of problem ? As mentioned elsewhere in this thread, this is discussed in detail in #630615. As touched on in the bug report, I think that being able to store 1.2GiB on /tmp is an unrealistic expectation. To qualify, I mean to expect that to work *by default*. If you want to store such large amounts of data, you will need to configure your system to handle that, either by: - provisioning of more swap and raising of the TMP_SIZE limit. - disabling RAMTMP and using a disc-backed filesystem (either the rootfs or dedicated /tmp mount). Again, as mentioned in the report, due to the wide variation in disc partitioning, filesystem utilisation and RAM capacity between systems, we don't currently make *any* guarantees regarding a minimum amount of space available in /tmp, when using a disc-backed /tmp. If the rootfs fills up, /tmp will cease to allow creation of new files. When using tmpfs, we do at least make a minimum guarantee of having a certain amount of storage available (which might albeit be used by other users). I'm not sure that I can really add more at this point than which was already included in the bug report. As a general rule, I think it's fair to say that if you want to *guarantee* the availability of that much storage, the defaults will not typically be sufficient.a But the defaults are just defaults--you are free to configure your system to satisfy your needs as you see fit. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013002850.gx28...@codelibre.net
Re: Bug#648306: The mingw* mess in Debian
Hi Ron, On Fri, 11 Nov 2011 07:36:28 +1030, Ron wrote: > I was hoping you'd actually been cc'd on this :) I was a few days behind debian-devel so I found out aboud the discussion thanks to Fabian's bug report, which you will have received too ;-). > On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote: > > As far as the naming is concerned, see #622276 for details. I've thought > > about splitting the packages up, with separate 32- and 64-bit targets, but > > I'm not sure whether replacing and providing the mingw32 packages would be > > correct, since mingw-w64 isn't a drop-in replacement (the triplets are > > different). If that's not a problem then why not! > > Ewww, why on earth did they change the triplet for the 32bit builds? > It's not actually a different architecture, or even a substantially > different toolchain. There is one major difference I know of: i686-pc-mingw32 (the official MinGW triplet) builds with Dwarf2 exception handling, whereas the -w64-mingw32 (the official MinGW-w64 triplets) build with SJLJ exception handling because Dwarf2 doesn't work on Win64 and isn't compatible with DLLs built with anything other than gcc. (See https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for details.) There may be other non-political differences I'm not aware of. > If you've actually got this all building from the mainline sources now, > I'd have been all for folding this into the original mingw packages and > having some sort of sensible (if somewhat interrupted :) continuity for > people down that track ... > > but if it's gratuitously incompatible, then I don't really know what to > do or think about that ... modulo pity for the people getting burned. I could be wrong about this, but I don't believe it's gratuitously incompatible. The thing is though that end-users are now used to the -w64-mingw32 triplets. > > The names for the 32-bit packages would probably be quite weird though > > since the upstream name is mingw-w64 (and I'd rather keep that in the > > package names...). > > I'm not sure I really follow this, what am I missing here? What exactly > are you taking from 'upstream' in this case? My understanding was that > the toolchain was mainline gcc/binutils now, and all that the w64 folk > were providing was the runtime library? Is that wrong? That's correct, so the only really upstream package is mingw-w64 which provides the headers and libraries required to target Windows (it's not even a runtime library since there is no non-gcc runtime library). The MinGW-w64 developers do submit patches against binutils and gcc now and again, so in a sense they're still providing the toolchain, they're just upstreaming everything instead of shipping patches. > mingw.org has been basically dead for quite some time now, the 'developer' > list has been closed to the public and the only apparent work going on > was for native windows installers. They were even claiming that building > it for platforms other than windows was officially completely unsupported. > All the old-blood developers appear to have moved on to other things, > presumably because the 'hard parts' have all been mainlined now. > > So sourcing the runtime from somewhere else now seems like a useful > proposition. But changing more than was really needed to do that does > make describing this as a "mess" look like a generous understatement ... > > Is it really that bad, and if so is it really too late to back away > slowly and make this less disruptive to established users? It would > be nice to actually have an orderly 'upgrade' path through this rather > than an "everything is different now" paradigm shift. It is just a > toolchain after all. For a rather old and settled architecture. I thought it better to follow the MinGW-w64 project's recommendations, including using their triplets. Because people still encounter bugs fairly regularly (see the bug trackers at https://sourceforge.net/tracker/?group_id=202880 and the mailing list archives), I believe we're better off if we can easily get support from upstream, and they're more inclined to help us out if we follow their guidelines. I'll try a build with the old triplets to see how that goes, and to figure out what kind of upgrade path we can provide... Regards, Stephen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013011743.38344...@sk2.org
Re: /tmp as tmpfs and consequence for imaging software
On Sat, Nov 12, 2011 at 11:25:12PM +0100, Josselin Mouette wrote: > Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit : > > Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : > > > You need to increase the swap size by the amount you'd use for /tmp. > > > > Well, the idea of such case is precisely to *not* use swap, but real > > disks. Such software already know how to manage its memory and > > disk-backed memory (thusly stored in /tmp) > > Practically speaking, the only significant difference is that files are > not forced to disk as early. That, and you don't have to do umpteen metadata writes (including barriers!) for every file written to. Real filesystems work with the assumption that both the files need to be durable and the filesystem itself must be consistent even after a crash, including caring about the disk controller "maliciously" reordering writes. We're speaking of ~ seven seeks + writes for creating an one-block file. Log-structured filesystems might not have such journal churn but are still worse than tmpfs. > Otherwise, if you have a large enough swap, pages of a file on a tmpfs > that are not used enough will be swapped. And pages of a file on a > regular filesystem that are used enough will be kept in the buffer cache. In other words, tmpfs never[1] performs worse than an actual filesystem. Usually the files won't be ever actually written to the disk, and if they will, tmpfs will work equivalently (anonymous vs file-backed pages), minus crash consistency costs. There's a configuration issue caused by taking space from a different pool, though. [1]. Currently, if there are multiple concurrent writers of large files, there will be fragmentation smart real filesystems have workarounds for. This could be avoided by hinting the kernel that if it swaps down a block, it should consider the next block of the same file rather than strictly following LRU order. Such logic is far simpler than what real filesystems have to do. -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013005928.gc1...@angband.pl
Re: /tmp as tmpfs and consequence for imaging software
On 12/11/11 23:25, Josselin Mouette wrote: > Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit : >> Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : >>> You need to increase the swap size by the amount you'd use for /tmp. >> >> Well, the idea of such case is precisely to *not* use swap, but real >> disks. Such software already know how to manage its memory and >> disk-backed memory (thusly stored in /tmp) > > Practically speaking, the only significant difference is that files are > not forced to disk as early. Otherwise, if you have a large enough swap, > pages of a file on a tmpfs that are not used enough will be swapped. And > pages of a file on a regular filesystem that are used enough will be > kept in the buffer cache. > There are another differences: When the system is swapping heavily, if you are not using a preempt kernel the hole system will become so unresponsive while the swapping process is taking place that even your mouse pointer will stop moving. And Debian kernel is no preempt. So, if having /tmp with tmpfs will make your system to swap more often (huge files on /tmp) then any performance gain by tmpfs will be buried by this swapping hell. Also, if you are near to run out of virtual memory (RAM+SWAP) for whatever reason: few ram, many apps open... an application can trigger the OOMKiller by simply writing data into /tmp if you are using tmpfs. > OTOH, for a wide range of applications that do a lot of small writes, > using tmpfs is a huge gain. > Linux already has a disk cache buffer that works very nice for this case of doing lot of small read/writes into a file. Also, when its time to flush the data to disk, or read data no previously cached, the kernel IO scheduler will take care of optimizing it in order to reduce the disk spinning and improve the performance. So... while is true that tmpfs is faster than using the disk for /tmp, it isn't such big deal. And IMHO I don't think that this performance gain outweighs so clearly the problems exposed that justify making tmpfs on /tmp the default on Debian. signature.asc Description: OpenPGP digital signature
Bug#648571: ITP: mha4mysql-manager -- Master High Availability Manager and tools for MySQL
Package: wnpp Severity: wishlist Owner: KURASHIKI Satoru * Package name: mha4mysql-manager Version : 0.52 Upstream Author : Yoshinori Matsunobu * URL : http://code.google.com/p/mysql-master-ha/ * License : GPL2 Programming Lang: Perl Description : Master High Availability Manager and tools for MySQL, Manager Package -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013034926.9813.61217.reportbug@localhost
Bug#648573: ITP: mha4mysql-node -- Master High Availability Manager and Tools for MySQL, Node Package
Package: wnpp Severity: wishlist Owner: KURASHIKI Satoru * Package name: mha4mysql-node Version : 0.52 Upstream Author : Yoshinori Matsunobu * URL : http://code.google.com/p/mysql-master-ha/ * License : GPL2 Programming Lang: Perl Description : Master High Availability Manager and Tools for MySQL, Node Package -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013040148.10869.47632.reportbug@localhost
Bug#648576: ITP: ruby-notify -- desktop notification on cross platforms
Package: wnpp Owner: Youhei SASAKI Severity: wishlist * Package name: ruby-notify Version : 0.3.0 Upstream Author : jugyo * URL or Web page : https://github.com/jugyo/notify * License : MIT Description : desktop notification on cross platforms The ruby-notify provides desktop notification function on cross platforms. . In Debian, the "notify" command execute "notify-send". --- Youhei SASAKI GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k474pock.wl%uwab...@gfd-dennou.org
Re: Periodic automake cleanup: removal of automake1.7 [and 1 more messages]
* Ian Jackson (ijack...@chiark.greenend.org.uk) wrote:
> Eric Dorland writes ("Re: Periodic automake cleanup: removal of automake1.7"):
> > The versions after 1.4 were where backwards-incompatible changes
> > started showing up. As a very unscientific census using google code
> > search, there are about 36,800 Makefile.in's generated by automake 1.4
> > on the web, versus 113,000 generated by automake 1.6 and later.
>
> This is a good reason to keep 1.4, at least for now and perhaps
> indefinitely.
>
> Michael Biebl writes ("Re: Periodic automake cleanup: removal of
> automake1.7"):
> > I don't think we should be advocating the usage of automake 1.4 by
> > shipping it in out next stable release. [...]
>
> Shipping an older version of a tool like automake is not "advocating
> [its] usage". It's making life less difficult for people who still
> need it.
>
> I don't imagine it takes much maintenance but of course I'm not saying
> that someone else ought to do the work. If the existing maintainer
> wants to get rid of automake1.4, I would be happy to take it over to
> keep it in the archive.
I'm happy to keep maintaining automake1.4 and I agree it should stay
in the archive, at least until wheezy is released.
> Ian.
>
>
--
Eric Dorland
ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
Re: /tmp as tmpfs and consequence for imaging software
On Sun, 2011-11-13 at 04:04 +0100, Carlos Alberto Lopez Perez wrote: > On 12/11/11 23:25, Josselin Mouette wrote: > > Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit : > >> Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : > >>> You need to increase the swap size by the amount you'd use for /tmp. > >> > >> Well, the idea of such case is precisely to *not* use swap, but real > >> disks. Such software already know how to manage its memory and > >> disk-backed memory (thusly stored in /tmp) > > > > Practically speaking, the only significant difference is that files are > > not forced to disk as early. Otherwise, if you have a large enough swap, > > pages of a file on a tmpfs that are not used enough will be swapped. And > > pages of a file on a regular filesystem that are used enough will be > > kept in the buffer cache. > > > There are another differences: > > > When the system is swapping heavily, if you are not using a preempt > kernel the hole system will become so unresponsive while the swapping > process is taking place that even your mouse pointer will stop moving. > And Debian kernel is no preempt. Linux does not busy-wait for disk I/O and will keep switching between tasks regardless of whether preemption is enabled. Further, since version 2.6.31-1~experimental.1, all official kernel packages have PREEMPT_VOLUNTARY enabled. The problem you are describing is that physical memory becomes almost full with the working set, dirty pages and write buffers and it is not possible to write data to disk fast enough to keep up with tasks that generate it. As this happens, the cache may have to shrink and reads will then miss the cache more often. Further, the kernel must block tasks that write to disk rather than allocating more write buffers for asynchronous writeback. Suddenly many of your tasks become blocked on the disk I/O queue. (Note that Linux 3.2 should improve I/O scheduling in this case so that the slowdown isn't quite so bad.) > So, if having /tmp with tmpfs will make your system to swap more often > (huge files on /tmp) then any performance gain by tmpfs will be buried > by this swapping hell. But a very similar problem can occur with I/O to a conventional filesystem. And it's worse in some ways - the kernel has to write filesystem blocks back in the right order to keep the filesystem consistent, which is not a concern for tmpfs. > Also, if you are near to run out of virtual memory (RAM+SWAP) for > whatever reason: few ram, many apps open... an application can trigger > the OOMKiller by simply writing data into /tmp if you are using tmpfs. In theory, yes. However the size of tmpfs is limited. > > OTOH, for a wide range of applications that do a lot of small writes, > > using tmpfs is a huge gain. > > > > Linux already has a disk cache buffer that works very nice for this case > of doing lot of small read/writes into a file. Also, when its time to > flush the data to disk, or read data no previously cached, the kernel IO > scheduler will take care of optimizing it in order to reduce the disk > spinning and improve the performance. That doesn't really help that much once the system is short of memory, though. > So... while is true that tmpfs is faster than using the disk for /tmp, > it isn't such big deal. > > > And IMHO I don't think that this performance gain outweighs so clearly > the problems exposed that justify making tmpfs on /tmp the default on > Debian. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
