All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH 1/2] tst_acquire_device: clear first sectors of LTP_DEV
Date: Wed, 24 Feb 2016 15:47:16 +0300	[thread overview]
Message-ID: <56CDA654.3040802@oracle.com> (raw)
In-Reply-To: <20160222103408.GA5530@rei.lan>

Hi!

On 02/22/2016 01:34 PM, Cyril Hrubis wrote:
> Hi!
>> As we see in [1] ZAP_BOOTBLOCK is defined on all archs except SPARC.
>> I could not find the exact reason why it's so, but tend to think
>> that it was implemented to let ext{2,3,4} be created on the first
>> partition of a Sun disk label. The thing is that with Sun disk labels
>> it's absolutely fine to have the first partition starting at sector 0,
>> which is used by the disk label itself:
>>
>> ~# fdisk -lu /dev/vdiska
>>
>> Disk /dev/vdiska (Sun disk label): 255 heads, 63 sectors, 3916 cylinders
>> Units = sectors of 1 * 512 bytes
>>
>>        Device Flag    Start       End    Blocks   Id  System
>> /dev/vdiska1             0   2104515   1052257+   1  Boot
>> /dev/vdiska2       2104515  62910540  30403012+  83  Linux native
>> /dev/vdiska3             0  62910540  31455270    5  Whole disk
>>
>> If mkfs.ext{2,3,4} overwrote the first two sectors, then
>> 'mkfs.ext{2,3,4} /dev/vdiska1' would destroy the disk label.
>>
>> Clearing the first 512k of LTP_DEV solves this issue. I don't expect
>> it to make a noticeable impact on test execution time. 512k is fine
>> to cover superblocks of all file systems supported by libblkid [2].
>> Just in case.
>
> Sounds reasonable to me. I guess that we can remove the special cases
> for the force flag once this is applied as well.
>

I committed the series. Thank you.

Regarding the force flag. Yes, we no longer need it now.

I tried to execute mount* test cases with ext2/ext3/xfs/btrfs file 
systems with the attached patch and they all passed.

So am I proceeding with a more formal patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkfs_no_force_flag.patch
Type: text/x-diff
Size: 906 bytes
Desc: not available
URL: <http://lists.linux.it/pipermail/ltp/attachments/20160224/f039870e/attachment.patch>

  reply	other threads:[~2016-02-24 12:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-20 13:34 [LTP] [RFC PATCH 1/2] tst_acquire_device: clear first sectors of LTP_DEV Stanislav Kholmanskikh
2016-02-20 13:34 ` [LTP] [PATCH 2/2] mkfs01.sh: use df -P Stanislav Kholmanskikh
2016-02-22 10:34   ` Cyril Hrubis
2016-02-22 10:34 ` [LTP] [RFC PATCH 1/2] tst_acquire_device: clear first sectors of LTP_DEV Cyril Hrubis
2016-02-24 12:47   ` Stanislav Kholmanskikh [this message]
2016-02-24 13:07     ` Cyril Hrubis

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=56CDA654.3040802@oracle.com \
    --to=stanislav.kholmanskikh@oracle.com \
    --cc=ltp@lists.linux.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.