|To:||Steve Lord <lord@xxxxxxx>, Sean Neakums <sneakums@xxxxxxxx>|
|Subject:||Re: file corruption during emacs build on XFS logical volume|
|From:||Seth Mos <knuffie@xxxxxxxxx>|
|Date:||Fri, 04 Jan 2002 21:26:06 +0100|
|Cc:||Linux XFS <linux-xfs@xxxxxxxxxxx>|
|References:||<6ug05mj6ah.fsf@xxxxxxxxxxxxx> <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@xxxxxxxxxxxxx> <6usn9mj7id.fsf@xxxxxxxxxxxxx> <6uofkaj6zj.fsf@xxxxxxxxxxxxx> <6ug05mj6ah.fsf@xxxxxxxxxxxxx>|
At 14:07 4-1-2002 -0600, Steve Lord wrote:
On Fri, 2002-01-04 at 12:54, Sean Neakums wrote: > begin Sean Neakums quotation: > > > I am now going to do a build of the upstream source and see if I can > > make the dump break on that too. I'm hopeful that it will, as the > > unexec code is the same in upstream as in the Debian emacs21 > > package. > > Yep, I just got me a dumped emacs binary full of NULs with the > original GNU source. OK, bingo, I can replicate this now, I too have a bad binary, it looks like the memory is getting reclaimed without getting flushed out to disk - which is not good at all. This actually gives me something to go on, hopefully it won't take too long to find now. Thanks for your persistance in generating a test case here.
This might explain the fs corruption that some other people saw as well on 2.4.17-xfs.
I can't remember who it was, i'll look it up. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: file corruption during emacs build on XFS logical volume, Steve Lord|
|Next by Date:||Re: file corruption during emacs build on XFS logical volume, Austin Gonyou|
|Previous by Thread:||Re: file corruption during emacs build on XFS logical volume, Steve Lord|
|Next by Thread:||Re: file corruption during emacs build on XFS logical volume, Austin Gonyou|
|Indexes:||[Date] [Thread] [Top] [All Lists]|