From: Eric Sandeen <sandeen@sandeen.net>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: "Yongqiang Yang" <xiaoqiangnk@gmail.com>,
xfs-oss <xfs@oss.sgi.com>,
coreutils@gnu.org, linux-ext4@vger.kernel.org,
ady <P@draigbrady.com>,
=?ISO-8859-1?Q?P=E1draig_Br?=@oss.sgi.com
Subject: Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?)
Date: Thu, 14 Apr 2011 11:49:19 -0500 [thread overview]
Message-ID: <4DA7258F.1080302@sandeen.net> (raw)
In-Reply-To: <20110414164811.GB21658@x4.trippels.de>
On 4/14/11 11:48 AM, Markus Trippelsdorf wrote:
> On 2011.04.14 at 11:31 -0500, Eric Sandeen wrote:
>> On 4/14/11 11:28 AM, Markus Trippelsdorf wrote:
>>
>> <snip>
>>
>>> Yes, but we're still trying to find out what caused the zeros in the
>>> binaries that coreutils installed on my system.
>>>
>>> Now the failure only happens when I use "gold" as my linker. With GNU ld
>>> everything is OK. But I thought this must be a timing issue, because
>>> gold is faster and the binaries in coreutils-8.11/src are all fine.
>>
>> maybe xfs_bmap (or filefrag) of the binaries with both linkers would be instructive; are they laid out significantly differently?
>>
>> does gold preallocate?
>
> Just checked and yes it does. That should explain the issue I was
> seeing.
Well, mystery solved there, at least!
Now for the fixing part :)
Thanks for checking, at least my view of the world is still intact ;)
-Eric
> bool
> Output_file::map_no_anonymous()
> {
> const int o = this->o_;
>
> // If the output file is not a regular file, don't try to mmap it;
> // instead, we'll mmap a block of memory (an anonymous buffer), and
> // then later write the buffer to the file.
> void* base;
> struct stat statbuf;
> if (o == STDOUT_FILENO || o == STDERR_FILENO
> || ::fstat(o, &statbuf) != 0
> || !S_ISREG(statbuf.st_mode)
> || this->is_temporary_)
> return false;
>
> // Ensure that we have disk space available for the file. If we
> // don't do this, it is possible that we will call munmap, close,
> // and exit with dirty buffers still in the cache with no assigned
> // disk blocks. If the disk is out of space at that point, the
> // output file will wind up incomplete, but we will have already
> // exited. The alternative to fallocate would be to use fdatasync,
> // but that would be a more significant performance hit.
> if (::posix_fallocate(o, 0, this->file_size_) < 0)
> gold_fatal(_("%s: %s"), this->name_, strerror(errno));
>
> // Map the file into memory.
> base = ::mmap(NULL, this->file_size_, PROT_READ | PROT_WRITE,
> MAP_SHARED, o, 0);
>
> // The mmap call might fail because of file system issues: the file
> // system might not support mmap at all, or it might not support
> // mmap with PROT_WRITE.
> if (base == MAP_FAILED)
> return false;
>
> this->map_is_anonymous_ = false;
> this->base_ = static_cast<unsigned char*>(base);
> return true;
> }
>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-04-14 16:45 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-14 10:26 Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?) Markus Trippelsdorf
2011-04-14 12:06 ` Markus Trippelsdorf
2011-04-14 14:02 ` Markus Trippelsdorf
2011-04-14 14:59 ` Pádraig Brady
2011-04-14 15:50 ` Eric Sandeen
2011-04-14 15:52 ` Pádraig Brady
2011-04-14 15:56 ` Eric Sandeen
2011-04-14 16:03 ` Markus Trippelsdorf
2011-04-14 16:14 ` Eric Sandeen
2011-04-14 16:21 ` Yongqiang Yang
2011-04-14 16:28 ` Markus Trippelsdorf
2011-04-14 16:31 ` Eric Sandeen
2011-04-14 16:48 ` Markus Trippelsdorf
2011-04-14 16:49 ` Eric Sandeen [this message]
2011-04-14 16:04 ` Yongqiang Yang
2011-04-14 16:10 ` Yongqiang Yang
2011-05-05 11:29 ` Pádraig Brady
2011-05-05 11:47 ` Yongqiang Yang
2011-04-14 17:27 ` Jim Meyering
2011-04-14 19:13 ` Pádraig Brady
2011-04-14 19:39 ` Jim Meyering
2011-04-14 22:59 ` Dave Chinner
2011-04-14 23:29 ` Pádraig Brady
2011-04-15 0:09 ` Dave Chinner
2011-04-15 5:01 ` Andreas Dilger
2011-04-16 0:50 ` Dave Chinner
2011-04-16 5:11 ` Andreas Dilger
2011-04-16 12:21 ` Theodore Tso
2011-04-18 0:40 ` Dave Chinner
2011-04-18 2:45 ` Andreas Dilger
2011-04-19 1:58 ` Yongqiang Yang
2011-04-19 2:59 ` Ted Ts'o
2011-04-19 3:05 ` Eric Sandeen
2011-04-21 20:12 ` Jim Meyering
2011-04-19 3:30 ` Yongqiang Yang
2011-04-19 4:14 ` Dave Chinner
2011-04-19 5:27 ` Christoph Hellwig
2011-04-19 3:44 ` Dave Chinner
2011-04-19 6:53 ` Yongqiang Yang
2011-04-19 7:45 ` Dave Chinner
2011-04-19 8:11 ` Yongqiang Yang
2011-04-19 14:05 ` Eric Sandeen
2011-04-19 14:09 ` Ted Ts'o
2011-04-19 14:13 ` Eric Sandeen
2011-04-19 16:01 ` Ted Ts'o
2011-04-20 1:53 ` Yongqiang Yang
2011-04-20 15:21 ` Christoph Hellwig
2011-04-20 17:21 ` Ted Ts'o
2011-04-19 21:08 ` Dave Chinner
2011-04-20 15:29 ` Christoph Hellwig
2011-04-16 6:05 ` Yongqiang Yang
2011-04-18 0:35 ` Dave Chinner
2011-04-15 8:53 ` Jim Meyering
2011-04-15 17:16 ` Christoph Hellwig
2011-04-15 17:24 ` Eric Blake
2011-04-15 17:26 ` Christoph Hellwig
2011-04-15 22:28 ` Andreas Dilger
2011-04-16 0:25 ` Dave Chinner
2011-04-14 14:39 ` Eric Sandeen
2011-04-20 14:39 ` Jim Meyering
2011-04-21 20:01 ` Jim Meyering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DA7258F.1080302@sandeen.net \
--to=sandeen@sandeen.net \
--cc==?ISO-8859-1?Q?P=E1draig_Br?=@oss.sgi.com \
--cc=P@draigbrady.com \
--cc=coreutils@gnu.org \
--cc=linux-ext4@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=xfs@oss.sgi.com \
--cc=xiaoqiangnk@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox