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>
next prev parent 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.