public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
* xfstests enospc tests not filling up file systems with transparent compression
@ 2015-09-10 20:09 Dušan Čolić
  2015-09-10 23:45 ` Theodore Ts'o
  0 siblings, 1 reply; 3+ messages in thread
From: Dušan Čolić @ 2015-09-10 20:09 UTC (permalink / raw)
  To: fstests

Hello,

There are various xfstests that try to fill up whole partition but
they give false positives on file systems with transparent compression
because they use compressible test files like input from /dev/zero.
Different tests use different ways to generate test file(s) so what
would be the preferred way to generate incompressible test files? Use
/dev/urandom instead /dev/zero?

Thanks

Dushan

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: xfstests enospc tests not filling up file systems with transparent compression
  2015-09-10 20:09 xfstests enospc tests not filling up file systems with transparent compression Dušan Čolić
@ 2015-09-10 23:45 ` Theodore Ts'o
  2015-09-11  0:14   ` Eric Sandeen
  0 siblings, 1 reply; 3+ messages in thread
From: Theodore Ts'o @ 2015-09-10 23:45 UTC (permalink / raw)
  To: Dušan Čolić; +Cc: fstests

On Thu, Sep 10, 2015 at 10:09:16PM +0200, Dušan Čolić wrote:
> 
> There are various xfstests that try to fill up whole partition but
> they give false positives on file systems with transparent compression
> because they use compressible test files like input from /dev/zero.
> Different tests use different ways to generate test file(s) so what
> would be the preferred way to generate incompressible test files? Use
> /dev/urandom instead /dev/zero?

I would expect that most tests would use fallocate to allocate space
for ENOSPC tests, since it's much faster than writing all zeros.

If a file system with tansparent compression is treating space
allocated with fallocate as "all zeros" and hence infinitely
compressible, I'd argue that it's buggy, since one of the documented
uses of fallocate is to force the file system to allocate space so
that future writes are guaranteed to succeed, so that the application
doesn't have to deal with ENOSPC errors at some inconvenient time.
(For example, in the case of a DVR, you want to know that you've
allocated enough space for that all-so-critical recording of the
season finale of "The Big Bang Theory", or that episode of "Sex and
the City" which you had missed.  :-)

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: xfstests enospc tests not filling up file systems with transparent compression
  2015-09-10 23:45 ` Theodore Ts'o
@ 2015-09-11  0:14   ` Eric Sandeen
  0 siblings, 0 replies; 3+ messages in thread
From: Eric Sandeen @ 2015-09-11  0:14 UTC (permalink / raw)
  To: Theodore Ts'o, Dušan Čolić; +Cc: fstests



On 9/10/15 6:45 PM, Theodore Ts'o wrote:
> On Thu, Sep 10, 2015 at 10:09:16PM +0200, Dušan Čolić wrote:
>>
>> There are various xfstests that try to fill up whole partition but
>> they give false positives on file systems with transparent compression
>> because they use compressible test files like input from /dev/zero.
>> Different tests use different ways to generate test file(s) so what
>> would be the preferred way to generate incompressible test files? Use
>> /dev/urandom instead /dev/zero?
> 
> I would expect that most tests would use fallocate to allocate space
> for ENOSPC tests, since it's much faster than writing all zeros.

Several of those tests are generic ones, designed to work on filesystems
like ext3 which don't support fallocate...

-Eric

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-09-11  0:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-10 20:09 xfstests enospc tests not filling up file systems with transparent compression Dušan Čolić
2015-09-10 23:45 ` Theodore Ts'o
2015-09-11  0:14   ` Eric Sandeen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox