linux-ext4 - Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Apr 2014 12:21:25 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	Lukáš Czerner <lczerner@...hat.com>,
	Dave Chinner <david@...morbit.com>, xfs@....sgi.com,
	lsf@...ts.linux-foundation.org,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of
 CPUs in build-all

On Thu, Apr 3, 2014 at 12:06 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> On 4/3/14, 11:35 AM, Theodore Ts'o wrote:
>
>>>  - There's an undocumented way to write results outside the source
>>> tree called RESULT_BASE.  It would be great if it were documented and
>>> spelled consistently.
>
> I'm not actually certain that it was intended to be used this way.
> See 1686f9ab "xfstests: Introduce a results directory"
> which explains just where this variable came from and what it's
> for...

Yeah.  A real solution should just create and overmount results.

Unfortunately, AFAICT it's currently impossible to create a mountpoint
with no underlying dentry or to overmount a symlink, so this can be a
bit awkward.

>>>  - SCRATCH_MNT needs to be in /etc/fstab.  I think that this should be
>>> changed or documented.  If the latter, then SCRATCH_DEV seems
>>> redundant.
>
> Hm, I've never needed SCRATCH_MNT in /etc/fstab...
>
>> The various test scripts do need to be able to find the device where
>> the file system lives, and parsing /etc/fstab would be awkward.  So if
>> your comment is that either the /etc/fstab entry shouldn't be
>> required, or the xfstests runtime environment should be able to derive
>> $SCRATCH_DEV automatically from $SCRATCH_MNT, or vice versa, instead
>
> I guess I don't know why you'd expect to derive one from the other...

Sigh.

If $SCRATCH_MNT is specified, then the line in /etc/fstab is
unnecessary.  If $SCRATCH_MNT is not specified, then /etc/fstab will
do the trick.

What does not work is specifying $SCRATCH_DIR [sic] but not adding an
fstab entry.  Oops.


--Andy
--
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