Re: Reiser4 und LZO compression
On Sun, 27 August 2006 01:04:28 -0700, Andrew Morton wrote: Like lib/inflate.c (and this new code should arguably be in lib/). The problem is that if we clean this up, we've diverged very much from the upstream implementation. So taking in fixes and features from upstream becomes harder and more error-prone. I've had an identical argument with Linus about lib/zlib_*. He decided that he didn't care about diverging, I went ahead and changed the code. In the process, I merged a couple of outstanding bugfixes and reduced memory consumption by 25%. Looks like Linus was right on that one. I'd suspect that the maturity of these utilities is such that we could afford to turn them into kernel code in the expectation that any future changes will be small. But it's not a completely simple call. (iirc the inflate code had a buffer overrun a while back, which was found and fixed in the upstream version). Dito in lib/zlib_*. lib/inflage.c is only used for the various in-kernel bootloaders to uncompress a kernel image. Anyone tampering with the image to cause a buffer overrun already owns the machine anyway. Whether any of our experiences with zlib apply to lzo remains a question, though. Jörn -- I've never met a human being who would want to read 17,000 pages of documentation, and if there was, I'd kill him to get him out of the gene pool. -- Joseph Costello
Re: XFS corruption during power-blackout
On Fri, 1 July 2005 14:58:39 -0500, David Masover wrote: Bryan Henderson wrote: [...] What you'd really like is to fsync a multi-file unit of work (transaction) -- and not just among open files. You'd like to open, write, and close 1000 files in a single transaction and then commit that transaction, with no syncing due to timers in the meantime. If you're really greedy, you'd also ask for complete rollback if the system fails before the commit. Both of these are planned for Reiser4. Or is it 4.1? Both are pretty trivial to implement for a tree-based fs like reiserfs. Non-trivial is the user interface. Not sure if sys_reiser is the answer to that. Jörn -- When people work hard for you for a pat on the back, you've got to give them that pat. -- Robert Heinlein
Re: XFS corruption during power-blackout
On Thu, 30 June 2005 11:46:27 -0700, Chris Wedgwood wrote: On Thu, Jun 30, 2005 at 12:30:20PM -0400, Bryan Henderson wrote: In others, it implements everything that was buffered when sync() started is hardened before the next sync() returns, That is what happens now. I'm not sure any other behavior makes sense does it? If it happens differently I would call that a bug. While I agree with all the rest, this part confuses me. Do you mean that sync() should altually return immediatly, but the second sync() block until all data present at the time of the previous sync() is hardened? Or do you rather mean that a single sync() should block until all data currently present is hardened? Jörn -- It is better to die of hunger having lived without grief and fear, than to live with a troubled spirit amid abundance. -- Epictetus
Re: XFS corruption during power-blackout
On Thu, 30 June 2005 13:32:23 -0700, Chris Wedgwood wrote: On Thu, Jun 30, 2005 at 09:44:37PM +0200, J?rn Engel wrote: Or do you rather mean that a single sync() should block until all data currently present is hardened? Logically sync() should return only after all dirty buffers that existed before sync() was called are flushed. That's what I thought. Thanks for the confirmation. Anything more than this (i.e. waiting on newly (since sync was called but before it returns) dirtied buffers) could live-lock (actually, this used to happen sometimes, I don't know if that's the case). ... and would be totally useless anyway, yep. Jörn -- The strong give up and move away, while the weak give up and stay. -- unknown
Re: -mm - 2.6.13 merge status
On Mon, 27 June 2005 10:49:19 +0300, Pekka J Enberg wrote:
#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); }
while(0)
+#define BUG_ON(condition) do { \
+ if (unlikely((condition) != 0)) { \
+ printk(kernel BUG '%s' at %s:%d!\n, #condition, __FILE__,
__LINE__); \
+ panic(BUG!); \
+ } \
+} while(0)
#endif
o How about those architectures, where BUG() and panic() are not the
same thing?
o Embedded people might prefer not to have the additional string
constants in the kernel. Some config option would ease their wrath.
And no, not all embedded people #define BUG() to nothing.
Jörn
--
Happiness isn't having what you want, it's wanting what you have.
-- unknown
Re: [PATCH] verbose BUG_ON reporting
On Mon, 27 June 2005 15:27:50 +0300, Pekka J Enberg wrote: On Mon, 27 Jun 2005, Andi Kleen wrote: It won't work for me because it'll bloat the kernel .text considerable. There is a reason why BUG is implemented like it is. Compare it. The assertion codes bloat the kernel all the same. So how about this instead? Removes my objections. I still wouldn't want to enable the config option, but maybe others do. Jörn -- A surrounded army must be given a way out. -- Sun Tzu
