linux-ext4 - Re: unexpected sync delays in dpkg for small pre-allocated files on ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 30 May 2016 14:04:47 -0500
From:	Jun He <jhe@...wisc.edu>
To:	linux-ext4@...r.kernel.org
Cc:	tytso@....edu
Subject: Re: unexpected sync delays in dpkg for small pre-allocated files on
 ext4

> On Tue, May 24, 2016 at 07:07:41PM +0200, Gernot Hillier wrote:
> > 
> > To me, the problem looks comparable to
> > https://bugzilla.kernel.org/show_bug.cgi?id=56821 (even if we don't see
> > a full hang and there's no RAID involved for us), so a closer look on
> > the SCSI layer or driver might be the next step?
> 
> What I would suggest is to create a small test case which compares the
> time it takes to allocate 1 megabyte of memory, zero it, and then
> write one megabytes of zeros using the write(2) system call.  Then try
> writing one megabytes of zero using the BLKZEROOUT ioctl.
> 
> I'm pretty sure you'll see same issue with BLKZEROOUT ioctl, but at
> this point, we'll be able to send bug reports to the SCSI and block
> layer developers with something that makes this very clear that it has
> nothing to do with ext4.
> 
> This way we can also do some differential diagnosis; given that I'm
> not seeing this complaint from most people, I suspect it will be a
> matter of adding some specific devices to a blacklist (so that even
> though the SCSI device claims to support WRITE SAME, we need to
> disable it because it has a really lousy implementation of the SCSI
> WRITE SAME command).
> 
> Cheers,
> 
> - Ted

I just want to add that I once experienced a similar problem: huge delay
with fallocate() and a SSD. It turns out block layer zeroouts extents by 
discarding them (blkdev_issue_zeroout()), and the Intel SSD is VERY slow
at discarding.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html