From: Amir Goldstein <[email protected]>
From: Amir Goldstein <[email protected]>
blkid knows to identify the ext4dev FSTYP of a partition that was
formatted with mkfs.ext4dev.
quota tools and various util-linux utils are also aware of ext4dev,
so ext4dev shares the same capabilities as ext4.
Signed-off-by: Amir Goldstein <[email protected]>
Tested-by: Sergey Ivanov <[email protected]>
---
ext4dev is used to test experimental ext4 code in mutual existance
with production ext4 code on the same system.
Specifically, ext4 snapshots code is available for testing as a
stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
(see http://next3.sf.net).
v1 -> v2:
- undo change of fsck -t $FSTYP to fsck.$FSTYP
common.defrag | 2 +-
common.quota | 4 ++--
common.rc | 10 +++++-----
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/common.defrag b/common.defrag
index 1bcf01d..4850803 100644
--- a/common.defrag
+++ b/common.defrag
@@ -26,7 +26,7 @@ _require_defrag()
xfs)
DEFRAG_PROG=/usr/sbin/xfs_fsr
;;
- ext4)
+ ext4|ext4dev)
DEFRAG_PROG=/usr/bin/e4defrag
;;
*)
diff --git a/common.quota b/common.quota
index 3c87ce1..b6d5f16 100644
--- a/common.quota
+++ b/common.quota
@@ -29,7 +29,7 @@ _require_quota()
[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
case $FSTYP in
- ext2|ext3|ext4|reiserfs)
+ ext2|ext3|ext4|ext4dev|reiserfs)
if [ ! -d /proc/sys/fs/quota ]; then
_notrun "Installed kernel does not support quotas"
fi
@@ -237,7 +237,7 @@ _check_quota_usage()
# Sync to get delalloc to disk
sync
VFS_QUOTA=0
- if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
+ if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
VFS_QUOTA=1
quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
fi
diff --git a/common.rc b/common.rc
index e634fbb..c510c66 100644
--- a/common.rc
+++ b/common.rc
@@ -65,7 +65,7 @@ _mount_opts()
nfs)
export MOUNT_OPTIONS=$NFS_MOUNT_OPTIONS
;;
- ext2|ext3|ext4)
+ ext2|ext3|ext4|ext4dev)
# acls & xattrs aren't turned on by default on ext$FOO
export MOUNT_OPTIONS="-o acl,user_xattr $EXT_MOUNT_OPTIONS"
;;
@@ -110,7 +110,7 @@ _mkfs_opts()
_fsck_opts()
{
case $FSTYP in
- ext2|ext3|ext4)
+ ext2|ext3|ext4|ext4dev)
export FSCK_OPTIONS="-nf"
;;
reiserfs)
@@ -326,10 +326,10 @@ _scratch_mkfs_sized()
xfs)
_scratch_mkfs_xfs -d size=$fssize -b size=$blocksize
;;
- ext2|ext3|ext4)
+ ext2|ext3|ext4|ext4dev)
/sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks
;;
- btrfs)
+ btrfs)
/sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize
;;
*)
@@ -354,7 +354,7 @@ _scratch_mkfs_geom()
xfs)
MKFS_OPTIONS+=" -b size=$blocksize, -d su=$sunit_bytes,sw=$swidth_mult"
;;
- ext4)
+ ext4|ext4dev)
MKFS_OPTIONS+=" -b $blocksize -E stride=$sunit_blocks,stripe_width=$swidth_blocks"
;;
*)
--
1.7.4.1
On Wed, Jun 01, 2011 at 03:56:52PM +0300, [email protected] wrote:
> From: Amir Goldstein <[email protected]>
>
> From: Amir Goldstein <[email protected]>
>
> blkid knows to identify the ext4dev FSTYP of a partition that was
> formatted with mkfs.ext4dev.
> quota tools and various util-linux utils are also aware of ext4dev,
> so ext4dev shares the same capabilities as ext4.
>
> Signed-off-by: Amir Goldstein <[email protected]>
> Tested-by: Sergey Ivanov <[email protected]>
> ---
> ext4dev is used to test experimental ext4 code in mutual existance
> with production ext4 code on the same system.
>
> Specifically, ext4 snapshots code is available for testing as a
> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
> (see http://next3.sf.net).
>
> v1 -> v2:
> - undo change of fsck -t $FSTYP to fsck.$FSTYP
>
> common.defrag | 2 +-
> common.quota | 4 ++--
> common.rc | 10 +++++-----
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/common.defrag b/common.defrag
> index 1bcf01d..4850803 100644
> --- a/common.defrag
> +++ b/common.defrag
> @@ -26,7 +26,7 @@ _require_defrag()
> xfs)
> DEFRAG_PROG=/usr/sbin/xfs_fsr
> ;;
> - ext4)
> + ext4|ext4dev)
> DEFRAG_PROG=/usr/bin/e4defrag
> ;;
> *)
> diff --git a/common.quota b/common.quota
> index 3c87ce1..b6d5f16 100644
> --- a/common.quota
> +++ b/common.quota
> @@ -29,7 +29,7 @@ _require_quota()
> [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
>
> case $FSTYP in
> - ext2|ext3|ext4|reiserfs)
> + ext2|ext3|ext4|ext4dev|reiserfs)
> if [ ! -d /proc/sys/fs/quota ]; then
> _notrun "Installed kernel does not support quotas"
> fi
> @@ -237,7 +237,7 @@ _check_quota_usage()
> # Sync to get delalloc to disk
> sync
> VFS_QUOTA=0
> - if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
> + if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
> VFS_QUOTA=1
> quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
> fi
Perhaps this should be changes to a case statement?
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
> On Wed, Jun 01, 2011 at 03:56:52PM +0300, [email protected] wrote:
>> From: Amir Goldstein <[email protected]>
>>
>> From: Amir Goldstein <[email protected]>
>>
>> blkid knows to identify the ext4dev FSTYP of a partition that was
>> formatted with mkfs.ext4dev.
>> quota tools and various util-linux utils are also aware of ext4dev,
>> so ext4dev shares the same capabilities as ext4.
>>
>> Signed-off-by: Amir Goldstein <[email protected]>
>> Tested-by: Sergey Ivanov <[email protected]>
>> ---
>> ext4dev is used to test experimental ext4 code in mutual existance
>> with production ext4 code on the same system.
>>
>> Specifically, ext4 snapshots code is available for testing as a
>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
>> (see http://next3.sf.net).
>>
>> v1 -> v2:
>> - undo change of fsck -t $FSTYP to fsck.$FSTYP
>>
>> ?common.defrag | ? ?2 +-
>> ?common.quota ?| ? ?4 ++--
>> ?common.rc ? ? | ? 10 +++++-----
>> ?3 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/common.defrag b/common.defrag
>> index 1bcf01d..4850803 100644
>> --- a/common.defrag
>> +++ b/common.defrag
>> @@ -26,7 +26,7 @@ _require_defrag()
>> ? ? ?xfs)
>> ? ? ? ? ?DEFRAG_PROG=/usr/sbin/xfs_fsr
>> ? ? ? ;;
>> - ? ?ext4)
>> + ? ?ext4|ext4dev)
>> ? ? ? ? ?DEFRAG_PROG=/usr/bin/e4defrag
>> ? ? ? ;;
>> ? ? ?*)
>> diff --git a/common.quota b/common.quota
>> index 3c87ce1..b6d5f16 100644
>> --- a/common.quota
>> +++ b/common.quota
>> @@ -29,7 +29,7 @@ _require_quota()
>> ? ? ?[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
>>
>> ? ? ?case $FSTYP in
>> - ? ?ext2|ext3|ext4|reiserfs)
>> + ? ?ext2|ext3|ext4|ext4dev|reiserfs)
>> ? ? ? if [ ! -d /proc/sys/fs/quota ]; then
>> ? ? ? ? ? _notrun "Installed kernel does not support quotas"
>> ? ? ? fi
>> @@ -237,7 +237,7 @@ _check_quota_usage()
>> ? ? ? # Sync to get delalloc to disk
>> ? ? ? sync
>> ? ? ? VFS_QUOTA=0
>> - ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
>> + ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
>> ? ? ? ? ? ? ? VFS_QUOTA=1
>> ? ? ? ? ? ? ? quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
>> ? ? ? fi
>
> Perhaps this should be changes to a case statement?
>
you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-)
> Cheers,
>
> Dave.
>
> --
> Dave Chinner
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
> On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
>> On Wed, Jun 01, 2011 at 03:56:52PM +0300, [email protected] wrote:
>>> From: Amir Goldstein <[email protected]>
>>>
>>> From: Amir Goldstein <[email protected]>
>>>
>>> blkid knows to identify the ext4dev FSTYP of a partition that was
>>> formatted with mkfs.ext4dev.
>>> quota tools and various util-linux utils are also aware of ext4dev,
>>> so ext4dev shares the same capabilities as ext4.
>>>
>>> Signed-off-by: Amir Goldstein <[email protected]>
>>> Tested-by: Sergey Ivanov <[email protected]>
>>> ---
>>> ext4dev is used to test experimental ext4 code in mutual existance
>>> with production ext4 code on the same system.
>>>
>>> Specifically, ext4 snapshots code is available for testing as a
>>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
>>> (see http://next3.sf.net).
>>>
>>> v1 -> v2:
>>> - undo change of fsck -t $FSTYP to fsck.$FSTYP
>>>
>>> ?common.defrag | ? ?2 +-
>>> ?common.quota ?| ? ?4 ++--
>>> ?common.rc ? ? | ? 10 +++++-----
>>> ?3 files changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/common.defrag b/common.defrag
>>> index 1bcf01d..4850803 100644
>>> --- a/common.defrag
>>> +++ b/common.defrag
>>> @@ -26,7 +26,7 @@ _require_defrag()
>>> ? ? ?xfs)
>>> ? ? ? ? ?DEFRAG_PROG=/usr/sbin/xfs_fsr
>>> ? ? ? ;;
>>> - ? ?ext4)
>>> + ? ?ext4|ext4dev)
>>> ? ? ? ? ?DEFRAG_PROG=/usr/bin/e4defrag
>>> ? ? ? ;;
>>> ? ? ?*)
>>> diff --git a/common.quota b/common.quota
>>> index 3c87ce1..b6d5f16 100644
>>> --- a/common.quota
>>> +++ b/common.quota
>>> @@ -29,7 +29,7 @@ _require_quota()
>>> ? ? ?[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
>>>
>>> ? ? ?case $FSTYP in
>>> - ? ?ext2|ext3|ext4|reiserfs)
>>> + ? ?ext2|ext3|ext4|ext4dev|reiserfs)
>>> ? ? ? if [ ! -d /proc/sys/fs/quota ]; then
>>> ? ? ? ? ? _notrun "Installed kernel does not support quotas"
>>> ? ? ? fi
>>> @@ -237,7 +237,7 @@ _check_quota_usage()
>>> ? ? ? # Sync to get delalloc to disk
>>> ? ? ? sync
>>> ? ? ? VFS_QUOTA=0
>>> - ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
>>> + ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
>>> ? ? ? ? ? ? ? VFS_QUOTA=1
>>> ? ? ? ? ? ? ? quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
>>> ? ? ? fi
>>
>> Perhaps this should be changes to a case statement?
>>
>
> you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-)
>
I rechecked the fsck -t ext4dev vs. fsck.ext4dev.
fsck -t ext4dev doesn't work for me :-(
Sergey has a newer version of util-linux-ng
see:
amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5
fsck from util-linux-ng 2.17.2
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7
e2fsck: Get a newer version of e2fsck!
amir@qalab:~/xfstests$ sudo fsck.ext4dev -nf /dev/sda5
e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011)
Checking snapshots: 1,done
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda5: 6596/6561792 files (3.6% non-contiguous), 1242522/26216064 blocks
amir@qalab:~/xfstests$
What do you thing, Dave?
Should xfstests rely on a non-buggy generic fsck util, or just
implement it's own
non-buggy generic fsck (invoke fsck.$FSTYP directly)
I am running a recent system (Ubuntu 11.4) and I don't thing that upgrading
util-linux should be a requirement for xfstests to work.
>> Cheers,
>>
>> Dave.
>>
>> --
>> Dave Chinner
>> [email protected]
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote:
> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
> >> On Wed, Jun 01, 2011 at 03:56:52PM +0300, [email protected] wrote:
> >>> From: Amir Goldstein <[email protected]>
> >>>
> >>> From: Amir Goldstein <[email protected]>
> >>>
> >>> blkid knows to identify the ext4dev FSTYP of a partition that was
> >>> formatted with mkfs.ext4dev.
> >>> quota tools and various util-linux utils are also aware of ext4dev,
> >>> so ext4dev shares the same capabilities as ext4.
> >>>
> >>> Signed-off-by: Amir Goldstein <[email protected]>
> >>> Tested-by: Sergey Ivanov <[email protected]>
> >>> ---
> >>> ext4dev is used to test experimental ext4 code in mutual existance
> >>> with production ext4 code on the same system.
> >>>
> >>> Specifically, ext4 snapshots code is available for testing as a
> >>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
> >>> (see http://next3.sf.net).
> >>>
> >>> v1 -> v2:
> >>> - undo change of fsck -t $FSTYP to fsck.$FSTYP
> >>>
> >>> ?common.defrag | ? ?2 +-
> >>> ?common.quota ?| ? ?4 ++--
> >>> ?common.rc ? ? | ? 10 +++++-----
> >>> ?3 files changed, 8 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/common.defrag b/common.defrag
> >>> index 1bcf01d..4850803 100644
> >>> --- a/common.defrag
> >>> +++ b/common.defrag
> >>> @@ -26,7 +26,7 @@ _require_defrag()
> >>> ? ? ?xfs)
> >>> ? ? ? ? ?DEFRAG_PROG=/usr/sbin/xfs_fsr
> >>> ? ? ? ;;
> >>> - ? ?ext4)
> >>> + ? ?ext4|ext4dev)
> >>> ? ? ? ? ?DEFRAG_PROG=/usr/bin/e4defrag
> >>> ? ? ? ;;
> >>> ? ? ?*)
> >>> diff --git a/common.quota b/common.quota
> >>> index 3c87ce1..b6d5f16 100644
> >>> --- a/common.quota
> >>> +++ b/common.quota
> >>> @@ -29,7 +29,7 @@ _require_quota()
> >>> ? ? ?[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
> >>>
> >>> ? ? ?case $FSTYP in
> >>> - ? ?ext2|ext3|ext4|reiserfs)
> >>> + ? ?ext2|ext3|ext4|ext4dev|reiserfs)
> >>> ? ? ? if [ ! -d /proc/sys/fs/quota ]; then
> >>> ? ? ? ? ? _notrun "Installed kernel does not support quotas"
> >>> ? ? ? fi
> >>> @@ -237,7 +237,7 @@ _check_quota_usage()
> >>> ? ? ? # Sync to get delalloc to disk
> >>> ? ? ? sync
> >>> ? ? ? VFS_QUOTA=0
> >>> - ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
> >>> + ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
> >>> ? ? ? ? ? ? ? VFS_QUOTA=1
> >>> ? ? ? ? ? ? ? quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
> >>> ? ? ? fi
> >>
> >> Perhaps this should be changes to a case statement?
> >>
> >
> > you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-)
> >
>
> I rechecked the fsck -t ext4dev vs. fsck.ext4dev.
> fsck -t ext4dev doesn't work for me :-(
> Sergey has a newer version of util-linux-ng
> see:
>
> amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5
> fsck from util-linux-ng 2.17.2
> e2fsck 1.41.14 (22-Dec-2010)
> /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7
> e2fsck: Get a newer version of e2fsck!
> amir@qalab:~/xfstests$ sudo fsck.ext4dev -nf /dev/sda5
> e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011)
> Checking snapshots: 1,done
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/sda5: 6596/6561792 files (3.6% non-contiguous), 1242522/26216064 blocks
> amir@qalab:~/xfstests$
>
> What do you thing, Dave?
> Should xfstests rely on a non-buggy generic fsck util,
For filessytems that use the generic fsck multiplexor, yes.
> or just
> implement it's own
> non-buggy generic fsck (invoke fsck.$FSTYP directly)
In general, no. XFS is a special case in that fsck.xfs is a no-op -
it does no checking at all and only returns values needed for init
scripts to work correctly. xfs_repair/xfs_check are for checking the
filesystem...
> I am running a recent system (Ubuntu 11.4) and I don't thing that upgrading
> util-linux should be a requirement for xfstests to work.
We do not try to support every buggy piece of crap out there - if a
newer version of util-linux has already fixed the problem, then use
that and we don't need to do anything special with xfstests at all.
If you've got bleeding edge filesystem code that requires using a
ext4dev fstyp and a new ext4 userspace, then I think that requiring
you to use a non-buggy util-linux is not a big deal....
---
Personally I think that ext4dev shouldn't be supported at all. A
special fstyp iwhile ext4 was being developed was, IMO, a stupid
thing to do in the first place, and I was happy when it died. It
should not be resurrected and propagated.
xfstests assumes that you are using a userspace that is current with
the version of the filesystem the kernel supports. If you are
running a development/special branch of ext4, then you need to be
running a userspace that understands it completely. If all you are
doing with the ext4dev fstyp is trying to vector to a different fsck
program that supports a new set of feature bits, then IMO you are
doing it all wrong.
Fundamentally, the filesystem is either ext4 or it isn't. If the
features are never going to make it into mainline ext4, then you
need a completely different fstype and full userspace support for
that fstype. Once you have that, you can add the fstype support to
xfstests. However, just using a different fstyp just to set a
certain set of feature flags is, again IMO, a pretty stupid way of
going about this.
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner <[email protected]> wrote:
> On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote:
>> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
>> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
>> >> On Wed, Jun 01, 2011 at 03:56:52PM +0300, [email protected] wrote:
>> >>> From: Amir Goldstein <[email protected]>
>> >>>
>> >>> From: Amir Goldstein <[email protected]>
>> >>>
>> >>> blkid knows to identify the ext4dev FSTYP of a partition that was
>> >>> formatted with mkfs.ext4dev.
>> >>> quota tools and various util-linux utils are also aware of ext4dev,
>> >>> so ext4dev shares the same capabilities as ext4.
>> >>>
>> >>> Signed-off-by: Amir Goldstein <[email protected]>
>> >>> Tested-by: Sergey Ivanov <[email protected]>
>> >>> ---
>> >>> ext4dev is used to test experimental ext4 code in mutual existance
>> >>> with production ext4 code on the same system.
>> >>>
>> >>> Specifically, ext4 snapshots code is available for testing as a
>> >>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
>> >>> (see http://next3.sf.net).
>> >>>
>> >>> v1 -> v2:
>> >>> - undo change of fsck -t $FSTYP to fsck.$FSTYP
>> >>>
>> >>> ?common.defrag | ? ?2 +-
>> >>> ?common.quota ?| ? ?4 ++--
>> >>> ?common.rc ? ? | ? 10 +++++-----
>> >>> ?3 files changed, 8 insertions(+), 8 deletions(-)
>> >>>
>> >>> diff --git a/common.defrag b/common.defrag
>> >>> index 1bcf01d..4850803 100644
>> >>> --- a/common.defrag
>> >>> +++ b/common.defrag
>> >>> @@ -26,7 +26,7 @@ _require_defrag()
>> >>> ? ? ?xfs)
>> >>> ? ? ? ? ?DEFRAG_PROG=/usr/sbin/xfs_fsr
>> >>> ? ? ? ;;
>> >>> - ? ?ext4)
>> >>> + ? ?ext4|ext4dev)
>> >>> ? ? ? ? ?DEFRAG_PROG=/usr/bin/e4defrag
>> >>> ? ? ? ;;
>> >>> ? ? ?*)
>> >>> diff --git a/common.quota b/common.quota
>> >>> index 3c87ce1..b6d5f16 100644
>> >>> --- a/common.quota
>> >>> +++ b/common.quota
>> >>> @@ -29,7 +29,7 @@ _require_quota()
>> >>> ? ? ?[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
>> >>>
>> >>> ? ? ?case $FSTYP in
>> >>> - ? ?ext2|ext3|ext4|reiserfs)
>> >>> + ? ?ext2|ext3|ext4|ext4dev|reiserfs)
>> >>> ? ? ? if [ ! -d /proc/sys/fs/quota ]; then
>> >>> ? ? ? ? ? _notrun "Installed kernel does not support quotas"
>> >>> ? ? ? fi
>> >>> @@ -237,7 +237,7 @@ _check_quota_usage()
>> >>> ? ? ? # Sync to get delalloc to disk
>> >>> ? ? ? sync
>> >>> ? ? ? VFS_QUOTA=0
>> >>> - ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
>> >>> + ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
>> >>> ? ? ? ? ? ? ? VFS_QUOTA=1
>> >>> ? ? ? ? ? ? ? quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
>> >>> ? ? ? fi
>> >>
>> >> Perhaps this should be changes to a case statement?
>> >>
>> >
>> > you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-)
>> >
>>
>> I rechecked the fsck -t ext4dev vs. fsck.ext4dev.
>> fsck -t ext4dev doesn't work for me :-(
>> Sergey has a newer version of ?util-linux-ng
>> see:
>>
>> amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5
>> fsck from util-linux-ng 2.17.2
>> e2fsck 1.41.14 (22-Dec-2010)
>> /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7
>> e2fsck: Get a newer version of e2fsck!
>> amir@qalab:~/xfstests$ sudo fsck.ext4dev -nf /dev/sda5
>> e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011)
>> Checking snapshots: 1,done
>> Pass 1: Checking inodes, blocks, and sizes
>> Pass 2: Checking directory structure
>> Pass 3: Checking directory connectivity
>> Pass 4: Checking reference counts
>> Pass 5: Checking group summary information
>> /dev/sda5: 6596/6561792 files (3.6% non-contiguous), 1242522/26216064 blocks
>> amir@qalab:~/xfstests$
>>
>> What do you thing, Dave?
>> Should xfstests rely on a non-buggy generic fsck util,
>
> For filessytems that use the generic fsck multiplexor, yes.
>
>> or just
>> implement it's own
>> non-buggy generic fsck (invoke fsck.$FSTYP directly)
>
> In general, no. XFS is a special case in that fsck.xfs is a no-op -
> it does no checking at all and only returns values needed for init
> scripts to work correctly. xfs_repair/xfs_check are for checking the
> filesystem...
>
>> I am running a recent system (Ubuntu 11.4) and I don't thing that upgrading
>> util-linux should be a requirement for xfstests to work.
>
> We do not try to support every buggy piece of crap out there - if a
> newer version of util-linux has already fixed the problem, then use
> that and we don't need to do anything special with xfstests at all.
> If you've got bleeding edge filesystem code that requires using a
> ext4dev fstyp and a new ext4 userspace, then I think that requiring
> you to use a non-buggy util-linux is not a big deal....
>
no. not a big deal at all.
> ---
>
> Personally I think that ext4dev shouldn't be supported at all. A
> special fstyp iwhile ext4 was being developed was, IMO, a stupid
> thing to do in the first place, and I was happy when it died. It
> should not be resurrected and propagated.
>
> xfstests assumes that you are using a userspace that is current with
> the version of the filesystem the kernel supports. If you are
> running a development/special branch of ext4, then you need to be
> running a userspace that understands it completely. If all you are
> doing with the ext4dev fstyp is trying to vector to a different fsck
> program that supports a new set of feature bits, then IMO you are
> doing it all wrong.
>
> Fundamentally, the filesystem is either ext4 or it isn't. If the
> features are never going to make it into mainline ext4, then you
> need a completely different fstype and full userspace support for
> that fstype. Once you have that, you can add the fstype support to
> xfstests. However, just using a different fstyp just to set a
> certain set of feature flags is, again IMO, a pretty stupid way of
> going about this.
>
The features are going into mainline, but are not there yet.
I did not invent the ext4dev standard, which is pretty well supported
by all relevant tools, but I find it very convenient for the testing.
Especially, when I expect my testers to be running a stable
distro release (i.e. F15 or Ubuntu 11.4) and be able to install
my experimental ext4dev module and utils, without it affecting
their (most likely) root ext4/ext3 fs.
> Cheers,
>
> Dave.
>
> --
> Dave Chinner
> [email protected]
>
On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote:
> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner <[email protected]> wrote:
> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote:
> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
> > Personally I think that ext4dev shouldn't be supported at all. A
> > special fstyp iwhile ext4 was being developed was, IMO, a stupid
> > thing to do in the first place, and I was happy when it died. It
> > should not be resurrected and propagated.
> >
> > xfstests assumes that you are using a userspace that is current with
> > the version of the filesystem the kernel supports. If you are
> > running a development/special branch of ext4, then you need to be
> > running a userspace that understands it completely. If all you are
> > doing with the ext4dev fstyp is trying to vector to a different fsck
> > program that supports a new set of feature bits, then IMO you are
> > doing it all wrong.
> >
> > Fundamentally, the filesystem is either ext4 or it isn't. If the
> > features are never going to make it into mainline ext4, then you
> > need a completely different fstype and full userspace support for
> > that fstype. Once you have that, you can add the fstype support to
> > xfstests. However, just using a different fstyp just to set a
> > certain set of feature flags is, again IMO, a pretty stupid way of
> > going about this.
> >
>
> The features are going into mainline, but are not there yet.
So using feature bits as they were intended is the right thing to
do, isn't it?
> I did not invent the ext4dev standard, which is pretty well supported
> by all relevant tools, but I find it very convenient for the testing.
As I understand it, ext4dev is deprecated and should not be used for
any new filesystems. When did that status change?
Or did you just start using it because it's convenient for your
purposes? What happens when someone else decides to use ext4dev for
testing incompatible development features because it is convenient
for them?
> Especially, when I expect my testers to be running a stable
> distro release (i.e. F15 or Ubuntu 11.4) and be able to install
> my experimental ext4dev module and utils, without it affecting
> their (most likely) root ext4/ext3 fs.
So get them to use an ext3, XFS, reiser or JFS root filesystem if
that's your major concern. That's long been a best practice for
configuring a filesystem test box - don't use the same filesystem
for your root/stable filesystems as the filesytsem you are testing.
e.g. If you pick ext3 for the root filesystem, then you can test
ext4, btrfs, xfs, etc changes without having to worry about whether
the development module being tested is going to affect your root
filesystem....
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Thu, Jun 2, 2011 at 9:40 AM, Dave Chinner <[email protected]> wrote:
> On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote:
>> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner <[email protected]> wrote:
>> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote:
>> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
>> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
>> > Personally I think that ext4dev shouldn't be supported at all. A
>> > special fstyp iwhile ext4 was being developed was, IMO, a stupid
>> > thing to do in the first place, and I was happy when it died. It
>> > should not be resurrected and propagated.
>> >
>> > xfstests assumes that you are using a userspace that is current with
>> > the version of the filesystem the kernel supports. If you are
>> > running a development/special branch of ext4, then you need to be
>> > running a userspace that understands it completely. If all you are
>> > doing with the ext4dev fstyp is trying to vector to a different fsck
>> > program that supports a new set of feature bits, then IMO you are
>> > doing it all wrong.
>> >
>> > Fundamentally, the filesystem is either ext4 or it isn't. If the
>> > features are never going to make it into mainline ext4, then you
>> > need a completely different fstype and full userspace support for
>> > that fstype. Once you have that, you can add the fstype support to
>> > xfstests. However, just using a different fstyp just to set a
>> > certain set of feature flags is, again IMO, a pretty stupid way of
>> > going about this.
>> >
>>
>> The features are going into mainline, but are not there yet.
>
> So using feature bits as they were intended is the right thing to
> do, isn't it?
I am not sure what you mean by that.
The fact that to this day fsck.ext2/3/4 have always been the same
file (hence support the same feature set) does not mean that they have
to be that way by design.
on my test system fsck.ext4dev must be used to test ext4dev, which has
newer features than ext4.
I fail to see the problem with that.
>
>> I did not invent the ext4dev standard, which is pretty well supported
>> by all relevant tools, but I find it very convenient for the testing.
>
> As I understand it, ext4dev is deprecated and should not be used for
> any new filesystems. When did that status change?
>
> Or did you just start using it because it's convenient for your
> purposes? ?What happens when someone else decides to use ext4dev for
> testing incompatible development features because it is convenient
> for them?
>
The way I see it, ext4dev is a tool for ext4 developers (and testers).
Anyone can use it for their own needs and it would be convenient for everyone.
I never suggested that Fedora push my ext4dev utils as a standard package.
But me and my group can use it to test the snapshots feature and Ted
and his group can use it to test the allocation clusters feature.
>> Especially, when I expect my testers to be running a stable
>> distro release (i.e. F15 or Ubuntu 11.4) and be able to install
>> my experimental ext4dev module and utils, without it affecting
>> their (most likely) root ext4/ext3 fs.
>
> So get them to use an ext3, XFS, reiser or JFS root filesystem if
> that's your major concern. That's long been a best practice for
> configuring a filesystem test box - don't use the same filesystem
> for your root/stable filesystems as the filesytsem you are testing.
>
> e.g. If you pick ext3 for the root filesystem, then you can test
> ext4, btrfs, xfs, etc changes without having to worry about whether
> the development module being tested is going to affect your root
> filesystem....
You make it sound as if I have a flock of testers out there waiting for
me to feed them with use cases to test and who abide to my setup
instructions.
Wake up call! this is not the case for me and for most developers.
If I'm lucky, I can get a e few testers who will say:
OK, if all I have to do is download this package and run 'make test'
I can spare an hour to play with it.
So, yes, it's true. There are other ways to accomplish what I am doing,
but I am going out of my way to try to make the life of developers and testers
easier and you are doing the exact opposite by raising objections to a rather
trivial and harmless patch.
Let me ask you this: which FSTYP will be useful to more developers
ext4dev or reiserfs?
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> [email protected]
>
On Thu, Jun 2, 2011 at 5:33 AM, Amir G. <[email protected]> wrote:
> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
>> On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
>>> On Wed, Jun 01, 2011 at 03:56:52PM +0300, [email protected] wrote:
>>>> From: Amir Goldstein <[email protected]>
>>>>
>>>> From: Amir Goldstein <[email protected]>
>>>>
>>>> blkid knows to identify the ext4dev FSTYP of a partition that was
>>>> formatted with mkfs.ext4dev.
>>>> quota tools and various util-linux utils are also aware of ext4dev,
>>>> so ext4dev shares the same capabilities as ext4.
>>>>
>>>> Signed-off-by: Amir Goldstein <[email protected]>
>>>> Tested-by: Sergey Ivanov <[email protected]>
>>>> ---
>>>> ext4dev is used to test experimental ext4 code in mutual existance
>>>> with production ext4 code on the same system.
>>>>
>>>> Specifically, ext4 snapshots code is available for testing as a
>>>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
>>>> (see http://next3.sf.net).
>>>>
>>>> v1 -> v2:
>>>> - undo change of fsck -t $FSTYP to fsck.$FSTYP
>>>>
>>>> ?common.defrag | ? ?2 +-
>>>> ?common.quota ?| ? ?4 ++--
>>>> ?common.rc ? ? | ? 10 +++++-----
>>>> ?3 files changed, 8 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/common.defrag b/common.defrag
>>>> index 1bcf01d..4850803 100644
>>>> --- a/common.defrag
>>>> +++ b/common.defrag
>>>> @@ -26,7 +26,7 @@ _require_defrag()
>>>> ? ? ?xfs)
>>>> ? ? ? ? ?DEFRAG_PROG=/usr/sbin/xfs_fsr
>>>> ? ? ? ;;
>>>> - ? ?ext4)
>>>> + ? ?ext4|ext4dev)
>>>> ? ? ? ? ?DEFRAG_PROG=/usr/bin/e4defrag
>>>> ? ? ? ;;
>>>> ? ? ?*)
>>>> diff --git a/common.quota b/common.quota
>>>> index 3c87ce1..b6d5f16 100644
>>>> --- a/common.quota
>>>> +++ b/common.quota
>>>> @@ -29,7 +29,7 @@ _require_quota()
>>>> ? ? ?[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
>>>>
>>>> ? ? ?case $FSTYP in
>>>> - ? ?ext2|ext3|ext4|reiserfs)
>>>> + ? ?ext2|ext3|ext4|ext4dev|reiserfs)
>>>> ? ? ? if [ ! -d /proc/sys/fs/quota ]; then
>>>> ? ? ? ? ? _notrun "Installed kernel does not support quotas"
>>>> ? ? ? fi
>>>> @@ -237,7 +237,7 @@ _check_quota_usage()
>>>> ? ? ? # Sync to get delalloc to disk
>>>> ? ? ? sync
>>>> ? ? ? VFS_QUOTA=0
>>>> - ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then
>>>> + ? ? if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then
>>>> ? ? ? ? ? ? ? VFS_QUOTA=1
>>>> ? ? ? ? ? ? ? quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
>>>> ? ? ? fi
>>>
>>> Perhaps this should be changes to a case statement?
>>>
>>
>> you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-)
>>
>
> I rechecked the fsck -t ext4dev vs. fsck.ext4dev.
> fsck -t ext4dev doesn't work for me :-(
> Sergey has a newer version of ?util-linux-ng
> see:
>
> amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5
> fsck from util-linux-ng 2.17.2
> e2fsck 1.41.14 (22-Dec-2010)
> /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7
> e2fsck: Get a newer version of e2fsck!
OK, after upgrading to newer util-linux and building it from git,
which also didn't help, I finally found who to blame - me.
I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is ext4.
fsck was picking up that entry and insisting that /dev/sda5 is ext4
(regardless of what it really is)
blkid isn't doing that silly thing.
Amir
On Thu, 2 Jun 2011, Amir G. wrote:
> On Thu, Jun 2, 2011 at 9:40 AM, Dave Chinner <[email protected]> wrote:
> > On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote:
> >> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner <[email protected]> wrote:
> >> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote:
> >> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
> >> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
> >> > Personally I think that ext4dev shouldn't be supported at all. A
> >> > special fstyp iwhile ext4 was being developed was, IMO, a stupid
> >> > thing to do in the first place, and I was happy when it died. It
> >> > should not be resurrected and propagated.
> >> >
> >> > xfstests assumes that you are using a userspace that is current with
> >> > the version of the filesystem the kernel supports. If you are
> >> > running a development/special branch of ext4, then you need to be
> >> > running a userspace that understands it completely. If all you are
> >> > doing with the ext4dev fstyp is trying to vector to a different fsck
> >> > program that supports a new set of feature bits, then IMO you are
> >> > doing it all wrong.
> >> >
> >> > Fundamentally, the filesystem is either ext4 or it isn't. If the
> >> > features are never going to make it into mainline ext4, then you
> >> > need a completely different fstype and full userspace support for
> >> > that fstype. Once you have that, you can add the fstype support to
> >> > xfstests. However, just using a different fstyp just to set a
> >> > certain set of feature flags is, again IMO, a pretty stupid way of
> >> > going about this.
> >> >
> >>
> >> The features are going into mainline, but are not there yet.
> >
> > So using feature bits as they were intended is the right thing to
> > do, isn't it?
>
> I am not sure what you mean by that.
> The fact that to this day fsck.ext2/3/4 have always been the same
> file (hence support the same feature set) does not mean that they have
> to be that way by design.
>
> on my test system fsck.ext4dev must be used to test ext4dev, which has
> newer features than ext4.
And that's perfectly fine, you can use whatever you want on you system.
> I fail to see the problem with that.
>
> >
> >> I did not invent the ext4dev standard, which is pretty well supported
> >> by all relevant tools, but I find it very convenient for the testing.
> >
> > As I understand it, ext4dev is deprecated and should not be used for
> > any new filesystems. When did that status change?
> >
> > Or did you just start using it because it's convenient for your
> > purposes? ?What happens when someone else decides to use ext4dev for
> > testing incompatible development features because it is convenient
> > for them?
> >
>
> The way I see it, ext4dev is a tool for ext4 developers (and testers).
> Anyone can use it for their own needs and it would be convenient for everyone.
> I never suggested that Fedora push my ext4dev utils as a standard package.
> But me and my group can use it to test the snapshots feature and Ted
> and his group can use it to test the allocation clusters feature.
ext4dev is not a tool for ext4 developers. It has been deprecated and
does not exist anymore, looking at kernel config there is nothing like
that. If you do not want to have different filesystem for your system
to be able to test ext4 without breaking your system ,than it is perfectly
fine to write yourself such helpers. But I do not see any reason for
pushing this stuff to other tools. In fact it should have been removed
from everywhere, since it does not exist anymore ... or has something
changed ? Are we resurrecting ext4dev ? Then we should start somewhere
else do not you think ?
>
>
> >> Especially, when I expect my testers to be running a stable
> >> distro release (i.e. F15 or Ubuntu 11.4) and be able to install
> >> my experimental ext4dev module and utils, without it affecting
> >> their (most likely) root ext4/ext3 fs.
> >
> > So get them to use an ext3, XFS, reiser or JFS root filesystem if
> > that's your major concern. That's long been a best practice for
> > configuring a filesystem test box - don't use the same filesystem
> > for your root/stable filesystems as the filesytsem you are testing.
> >
> > e.g. If you pick ext3 for the root filesystem, then you can test
> > ext4, btrfs, xfs, etc changes without having to worry about whether
> > the development module being tested is going to affect your root
> > filesystem....
>
> You make it sound as if I have a flock of testers out there waiting for
> me to feed them with use cases to test and who abide to my setup
> instructions.
>
> Wake up call! this is not the case for me and for most developers.
> If I'm lucky, I can get a e few testers who will say:
> OK, if all I have to do is download this package and run 'make test'
> I can spare an hour to play with it.
>
> So, yes, it's true. There are other ways to accomplish what I am doing,
> but I am going out of my way to try to make the life of developers and testers
> easier and you are doing the exact opposite by raising objections to a rather
> trivial and harmless patch.
What is easier for testers and developers ? I fail to see the reason for
including non-existing FSTYP into xfstests while it should be forgotten
by now. Just provide sources with whatever fs name you choose (or just
patches for ext4 preferably), provide patches to e2fsprogs and patches to
xfstests if you want people to test with it. And it should be easy for every
tester, or developer to use it, shouldn't it ? Is that a problem ?
-Lukas
>
> Let me ask you this: which FSTYP will be useful to more developers
> ext4dev or reiserfs?
>
> >
> > Cheers,
> >
> > Dave.
> > --
> > Dave Chinner
> > [email protected]
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Thu, Jun 2, 2011 at 3:10 PM, Lukas Czerner <[email protected]> wrote:
> On Thu, 2 Jun 2011, Amir G. wrote:
>
>> On Thu, Jun 2, 2011 at 9:40 AM, Dave Chinner <[email protected]> wrote:
>> > On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote:
>> >> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner <[email protected]> wrote:
>> >> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote:
>> >> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. <[email protected]> wrote:
>> >> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner <[email protected]> wrote:
>> >> > Personally I think that ext4dev shouldn't be supported at all. A
>> >> > special fstyp iwhile ext4 was being developed was, IMO, a stupid
>> >> > thing to do in the first place, and I was happy when it died. It
>> >> > should not be resurrected and propagated.
>> >> >
>> >> > xfstests assumes that you are using a userspace that is current with
>> >> > the version of the filesystem the kernel supports. If you are
>> >> > running a development/special branch of ext4, then you need to be
>> >> > running a userspace that understands it completely. If all you are
>> >> > doing with the ext4dev fstyp is trying to vector to a different fsck
>> >> > program that supports a new set of feature bits, then IMO you are
>> >> > doing it all wrong.
>> >> >
>> >> > Fundamentally, the filesystem is either ext4 or it isn't. If the
>> >> > features are never going to make it into mainline ext4, then you
>> >> > need a completely different fstype and full userspace support for
>> >> > that fstype. Once you have that, you can add the fstype support to
>> >> > xfstests. However, just using a different fstyp just to set a
>> >> > certain set of feature flags is, again IMO, a pretty stupid way of
>> >> > going about this.
>> >> >
>> >>
>> >> The features are going into mainline, but are not there yet.
>> >
>> > So using feature bits as they were intended is the right thing to
>> > do, isn't it?
>>
>> I am not sure what you mean by that.
>> The fact that to this day fsck.ext2/3/4 have always been the same
>> file (hence support the same feature set) does not mean that they have
>> to be that way by design.
>>
>> on my test system fsck.ext4dev must be used to test ext4dev, which has
>> newer features than ext4.
>
> And that's perfectly fine, you can use whatever you want on you system.
>
>> I fail to see the problem with that.
>>
>> >
>> >> I did not invent the ext4dev standard, which is pretty well supported
>> >> by all relevant tools, but I find it very convenient for the testing.
>> >
>> > As I understand it, ext4dev is deprecated and should not be used for
>> > any new filesystems. When did that status change?
>> >
>> > Or did you just start using it because it's convenient for your
>> > purposes? ?What happens when someone else decides to use ext4dev for
>> > testing incompatible development features because it is convenient
>> > for them?
>> >
>>
>> The way I see it, ext4dev is a tool for ext4 developers (and testers).
>> Anyone can use it for their own needs and it would be convenient for everyone.
>> I never suggested that Fedora push my ext4dev utils as a standard package.
>> But me and my group can use it to test the snapshots feature and Ted
>> and his group can use it to test the allocation clusters feature.
>
> ext4dev is not a tool for ext4 developers. It has been deprecated and
> does not exist anymore, looking at kernel config there is nothing like
> that. If you do not want to have different filesystem for your system
> to be able to test ext4 without breaking your system ,than it is perfectly
> fine to write yourself such helpers. But I do not see any reason for
> pushing this stuff to other tools. In fact it should have been removed
> from everywhere, since it does not exist anymore ... or has something
> changed ? Are we resurrecting ext4dev ? Then we should start somewhere
> else do not you think ?
>
Ted actually brought this up in our ext4 developers meeting on LSF.
He said we could register an ext4 module with the ext4dev external symbols
and it would be useful for testing, since we already have all those tools that
are aware of ext4dev.
I am still using a more low-tech method of cloning ext4 (sed) to build
a standalone ext4dev module for testing, but it's the same principle.
>>
>>
>> >> Especially, when I expect my testers to be running a stable
>> >> distro release (i.e. F15 or Ubuntu 11.4) and be able to install
>> >> my experimental ext4dev module and utils, without it affecting
>> >> their (most likely) root ext4/ext3 fs.
>> >
>> > So get them to use an ext3, XFS, reiser or JFS root filesystem if
>> > that's your major concern. That's long been a best practice for
>> > configuring a filesystem test box - don't use the same filesystem
>> > for your root/stable filesystems as the filesytsem you are testing.
>> >
>> > e.g. If you pick ext3 for the root filesystem, then you can test
>> > ext4, btrfs, xfs, etc changes without having to worry about whether
>> > the development module being tested is going to affect your root
>> > filesystem....
>>
>> You make it sound as if I have a flock of testers out there waiting for
>> me to feed them with use cases to test and who abide to my setup
>> instructions.
>>
>> Wake up call! this is not the case for me and for most developers.
>> If I'm lucky, I can get a e few testers who will say:
>> OK, if all I have to do is download this package and run 'make test'
>> I can spare an hour to play with it.
>>
>> So, yes, it's true. There are other ways to accomplish what I am doing,
>> but I am going out of my way to try to make the life of developers and testers
>> easier and you are doing the exact opposite by raising objections to a rather
>> trivial and harmless patch.
>
> What is easier for testers and developers ? I fail to see the reason for
> including non-existing FSTYP into xfstests while it should be forgotten
> by now. Just provide sources with whatever fs name you choose (or just
> patches for ext4 preferably), provide patches to e2fsprogs and patches to
> xfstests if you want people to test with it. And it should be easy for every
> tester, or developer to use it, shouldn't it ? Is that a problem ?
Yes, it is a problem. You are thinking in terms of a developer who builds
new kernels on a daily basis.
Back in the time, when I developed next3, I asked some friend and
people in the community
if they could test it.
It turned out that they don't even know how to build a kernel and they
don't want
to invest the time in doing that.
This is when I realized that to get to a wider audience of testers, I
need to make the testing
process E A S Y !
And by E A S Y, I mean:
1. Take a Fedora 15 system
2. download http://next3.sourceforge.net/files/1.0.13/ext4dev_snapshots-1.0.13-x86_64.tar.gz
3. tar xfz ext4dev_snapshots-1.0.13-x86_64.tar.gz && cd ext4dev_snapshots-1.0.13
4. make && sudo make install && sudo make test
That's it! it takes no more than 5 minutes and your system remains unaffected
by installed tools.
Now, if the patch in question is accepted to xfstests, testing the
experimental fs would
be as E A S Y as:
5. sudo mkfs.ext4dev -O has_snapshot /dev/sda5
6. sudo mount /dev/sda5 /mnt/test
7. cd ~/xfstests && sudo ./check (assuming those are your
TEST_DEV/TEST_DIR above)
Seriously, guys! This thread is becoming ridiculous.
xfstests is not a tools for an obscure target market - it's for us.
It should be used by developers to test their patches.
Why make it so difficult if I state very clearly that it helps me???
Can I get at least one Yay here? Ted? Eric? Anyone?
And look at the patch for heaven's sake (which was left behind in the heat
of the discussion) , it's miserably harmless.
Amir.
From da25ccc0910847b0aaddac1b01f223890244f223 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <[email protected]>
Date: Tue, 31 May 2011 18:43:17 +0300
Subject: [PATCH v3] xfstests: add support for ext4dev FSTYP
blkid knows to identify the ext4dev FSTYP of a partition that was
formatted with mkfs.ext4dev.
quota tools and various util-linux utils are also aware of ext4dev,
so ext4dev shares the same capabilities as ext4.
Signed-off-by: Amir Goldstein <[email protected]>
Tested-by: Sergey Ivanov <[email protected]>
---
ext4dev is used to test experimental ext4 code in mutual existance
with production ext4 code on the same system.
Specifically, ext4 snapshots code is available for testing as a
stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4
(see http://next3.sf.net).
v2 -> v3:
- change if to case statement
v1 -> v2:
- undo change of fsck -t $FSTYP to fsck.$FSTYP
common.defrag | 2 +-
common.quota | 10 +++++++---
common.rc | 10 +++++-----
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/common.defrag b/common.defrag
index 1bcf01d..4850803 100644
--- a/common.defrag
+++ b/common.defrag
@@ -26,7 +26,7 @@ _require_defrag()
xfs)
DEFRAG_PROG=/usr/sbin/xfs_fsr
;;
- ext4)
+ ext4|ext4dev)
DEFRAG_PROG=/usr/bin/e4defrag
;;
*)
diff --git a/common.quota b/common.quota
index 3c87ce1..9736306 100644
--- a/common.quota
+++ b/common.quota
@@ -29,7 +29,7 @@ _require_quota()
[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed"
case $FSTYP in
- ext2|ext3|ext4|reiserfs)
+ ext2|ext3|ext4|ext4dev|reiserfs)
if [ ! -d /proc/sys/fs/quota ]; then
_notrun "Installed kernel does not support quotas"
fi
@@ -237,10 +237,14 @@ _check_quota_usage()
# Sync to get delalloc to disk
sync
VFS_QUOTA=0
- if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP
= "reiserfs" ]; then
+ case $FSTYP in
+ ext2|ext3|ext4|ext4dev|reiserfs)
VFS_QUOTA=1
quotaon -f -u -g $SCRATCH_MNT 2>/dev/null
- fi
+ ;;
+ *)
+ ;;
+ esac
repquota -u -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch |
sort >$tmp.user.orig
repquota -g -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch |
diff --git a/common.rc b/common.rc
index e634fbb..c510c66 100644
--- a/common.rc
+++ b/common.rc
@@ -65,7 +65,7 @@ _mount_opts()
nfs)
export MOUNT_OPTIONS=$NFS_MOUNT_OPTIONS
;;
- ext2|ext3|ext4)
+ ext2|ext3|ext4|ext4dev)
# acls & xattrs aren't turned on by default on ext$FOO
export MOUNT_OPTIONS="-o acl,user_xattr $EXT_MOUNT_OPTIONS"
;;
@@ -110,7 +110,7 @@ _mkfs_opts()
_fsck_opts()
{
case $FSTYP in
- ext2|ext3|ext4)
+ ext2|ext3|ext4|ext4dev)
export FSCK_OPTIONS="-nf"
;;
reiserfs)
@@ -326,10 +326,10 @@ _scratch_mkfs_sized()
xfs)
_scratch_mkfs_xfs -d size=$fssize -b size=$blocksize
;;
- ext2|ext3|ext4)
+ ext2|ext3|ext4|ext4dev)
/sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks
;;
- btrfs)
+ btrfs)
/sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize
;;
*)
@@ -354,7 +354,7 @@ _scratch_mkfs_geom()
xfs)
MKFS_OPTIONS+=" -b size=$blocksize, -d su=$sunit_bytes,sw=$swidth_mult"
;;
- ext4)
+ ext4|ext4dev)
MKFS_OPTIONS+=" -b $blocksize -E
stride=$sunit_blocks,stripe_width=$swidth_blocks"
;;
*)
--
1.7.4.1
On Thu, 2 Jun 2011, Amir G. wrote:
--snip--
>
> Ted actually brought this up in our ext4 developers meeting on LSF.
> He said we could register an ext4 module with the ext4dev external symbols
> and it would be useful for testing, since we already have all those tools that
> are aware of ext4dev.
I know, but my point is still valid. why to introduce non-existing FSTYP
into other tools, this is not proper course of action. If the goal is
really resurrect ext4dev we should do this first.
>
> I am still using a more low-tech method of cloning ext4 (sed) to build
> a standalone ext4dev module for testing, but it's the same principle.
>
> >>
> >>
--snip--
> >>
> >> So, yes, it's true. There are other ways to accomplish what I am doing,
> >> but I am going out of my way to try to make the life of developers and testers
> >> easier and you are doing the exact opposite by raising objections to a rather
> >> trivial and harmless patch.
> >
> > What is easier for testers and developers ? I fail to see the reason for
> > including non-existing FSTYP into xfstests while it should be forgotten
> > by now. Just provide sources with whatever fs name you choose (or just
> > patches for ext4 preferably), provide patches to e2fsprogs and patches to
> > xfstests if you want people to test with it. And it should be easy for every
> > tester, or developer to use it, shouldn't it ? Is that a problem ?
>
> Yes, it is a problem. You are thinking in terms of a developer who builds
> new kernels on a daily basis.
> Back in the time, when I developed next3, I asked some friend and
> people in the community
> if they could test it.
> It turned out that they don't even know how to build a kernel and they
> don't want
> to invest the time in doing that.
> This is when I realized that to get to a wider audience of testers, I
> need to make the testing
> process E A S Y !
>
> And by E A S Y, I mean:
> 1. Take a Fedora 15 system
> 2. download http://next3.sourceforge.net/files/1.0.13/ext4dev_snapshots-1.0.13-x86_64.tar.gz
> 3. tar xfz ext4dev_snapshots-1.0.13-x86_64.tar.gz && cd ext4dev_snapshots-1.0.13
> 4. make && sudo make install && sudo make test
So you're saying that you can not patch xfstests (and other) sources in the
make time ??
Thanks!
-Lukas
On 6/2/11 2:16 AM, Amir G. wrote:
> OK, after upgrading to newer util-linux and building it from git,
> which also didn't help, I finally found who to blame - me.
> I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is ext4.
> fsck was picking up that entry and insisting that /dev/sda5 is ext4
> (regardless of what it really is)
> blkid isn't doing that silly thing.
>
> Amir
So where are we at with all this?
I don't really mind adding ext4dev to FSTYP case statements, it -is- something which blkid could, in theory, still return, and making xfstests cope with that and try to invoke fsck -t ext4dev doesn't bother me too much. It is sadly an fs type embedded into a few tools.
But other than that, I don't think we should be making changes to upstream projects based on your current development hacks (I don't mean hack in a bad way, just that running sed across ext4 to create your custom filesystem for testing should not require upstream projects to change...)
So I'm ok with sprinkling "ext4|ext4dev" around if necessary. Anyone else disagree?
-Eric
On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
> On 6/2/11 2:16 AM, Amir G. wrote:
>> OK, after upgrading to newer util-linux and building it from git,
>> which also didn't help, I finally found who to blame - me.
>> I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is ext4.
>> fsck was picking up that entry and insisting that /dev/sda5 is ext4
>> (regardless of what it really is)
>> blkid isn't doing that silly thing.
>
> So where are we at with all this?
>
> I don't really mind adding ext4dev to FSTYP case statements, it -is- something which blkid could, in theory, still return, and making xfstests cope with that and try to invoke fsck -t ext4dev doesn't bother me too much. It is sadly an fs type embedded into a few tools.
I'm perfectly OK with using ext4dev as a filesystem type that allows testing
changes to ext4 on a system that is already running ext4 as the root fs.
> But other than that, I don't think we should be making changes to upstream projects based on your current development hacks (I don't mean hack in a bad way, just that running sed across ext4 to create your custom filesystem for testing should not require upstream projects to change...)
No, but it's not like this is affecting a lot of tools, just one that is
used by filesystem developers.
> So I'm ok with sprinkling "ext4|ext4dev" around if necessary. Anyone else disagree?
The other alternative is to change all of the "ext2|ext3|ext4|ext4dev" case
statements to be "ext[2-9]*", or "ext[3-9]*", or "ext[4-9]*" for checks that
are only valid for newer codes and be done with it. It's a lot easier to
read, and we don't have to change it again should we ever get ext5 or whatever
(hopefully btrfs will be ready before that, but who knows).
Cheers, Andreas
On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote:
> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
> > I don't really mind adding ext4dev to FSTYP case statements, it
> > -is- something which blkid could, in theory, still return, and
> > making xfstests cope with that and try to invoke fsck -t ext4dev
> > doesn't bother me too much. It is sadly an fs type embedded into
> > a few tools.
>
> I'm perfectly OK with using ext4dev as a filesystem type that allows testing
> changes to ext4 on a system that is already running ext4 as the root fs.
My take on this is that way too much time has been spent this subject.
Being able to use ext4dev is useful, and given that we have all of
this support in our existing system tools, why not use it to make ext4
development more efficient/easy? As a bonus you can build the ext4dev
as a module, and that means you the compile/edit/debug cycle can be
much faster since you can avoid doing a reboot, for those
circumstances where using KVM is not possible/convenient. Personally,
I normally use KVM these days, but I can imagine situations where
using ext4dev would be a better way to go. For example, I'd probably
use KVM on my laptop, but for testing on production servers in a data
center, I'd probably use ext4dev, for a variety of local deployment
considerations that's not worth going into here.
That being said, whether or not we modify xfstests seems to be a moot
point. In order for me to do my bigalloc development, I've been
patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and
"/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". It's a 3 line change. Not
a big deal. I've been making this change using /bin/ed after
installing xfstests. So if the XFS folks want to veto this change ---
who cares? It's not hard to make the change locally in order to make
xfstests.
On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't
see why it's so important that it clings to "fsck -t $FSTYP" instead
of using "fsck.$FSTYP". There's no real benefit to calling the fsck
driver; it's just an extra fork and exec, and xfstests is being
inconsistent by insisting on the use of the fsck driver, but not using
the mkfs driver.
But that being said, hacking xfstests is not hard, and if Dave and/or
Eric feels strongly about resisting this change, it's not worth a lot
of time, one way or another....
- Ted
On Thu, Jun 02, 2011 at 09:59:35AM -0500, Eric Sandeen wrote:
> On 6/2/11 2:16 AM, Amir G. wrote:
>
> > OK, after upgrading to newer util-linux and building it from
> > git, which also didn't help, I finally found who to blame - me.
> > I had an old (noauto) entry in /etc/fstab which claimed that
> > /dev/sda5 is ext4. fsck was picking up that entry and insisting
> > that /dev/sda5 is ext4 (regardless of what it really is) blkid
> > isn't doing that silly thing.
> >
> > Amir
>
> So where are we at with all this?
>
> I don't really mind adding ext4dev to FSTYP case statements, it
> -is- something which blkid could, in theory, still return, and
> making xfstests cope with that and try to invoke fsck -t ext4dev
> doesn't bother me too much. It is sadly an fs type embedded into
> a few tools.
>
> But other than that, I don't think we should be making changes to
> upstream projects based on your current development hacks (I don't
> mean hack in a bad way, just that running sed across ext4 to
> create your custom filesystem for testing should not require
> upstream projects to change...)
>
> So I'm ok with sprinkling "ext4|ext4dev" around if necessary.
> Anyone else disagree?
Іf it is ext4 community decides that ext4dev is not deprecated then
I don't have any objection. It won't cause me any PEBKAC problems.
;)
Cheers,
Dave.
--
Dave Chinner
[email protected]
On 6/2/11 7:36 PM, Ted Ts'o wrote:
> On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote:
>> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
>>> I don't really mind adding ext4dev to FSTYP case statements, it
>>> -is- something which blkid could, in theory, still return, and
>>> making xfstests cope with that and try to invoke fsck -t ext4dev
>>> doesn't bother me too much. It is sadly an fs type embedded into
>>> a few tools.
>>
>> I'm perfectly OK with using ext4dev as a filesystem type that allows testing
>> changes to ext4 on a system that is already running ext4 as the root fs.
>
> My take on this is that way too much time has been spent this subject.
> Being able to use ext4dev is useful, and given that we have all of
> this support in our existing system tools, why not use it to make ext4
> development more efficient/easy? As a bonus you can build the ext4dev
> as a module, and that means you the compile/edit/debug cycle can be
> much faster since you can avoid doing a reboot, for those
> circumstances where using KVM is not possible/convenient. Personally,
> I normally use KVM these days, but I can imagine situations where
> using ext4dev would be a better way to go. For example, I'd probably
> use KVM on my laptop, but for testing on production servers in a data
> center, I'd probably use ext4dev, for a variety of local deployment
> considerations that's not worth going into here.
>
> That being said, whether or not we modify xfstests seems to be a moot
> point. In order for me to do my bigalloc development, I've been
> patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and
> "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". It's a 3 line change. Not
> a big deal. I've been making this change using /bin/ed after
> installing xfstests. So if the XFS folks want to veto this change ---
> who cares? It's not hard to make the change locally in order to make
> xfstests.
>
> On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't
> see why it's so important that it clings to "fsck -t $FSTYP" instead
> of using "fsck.$FSTYP". There's no real benefit to calling the fsck
> driver; it's just an extra fork and exec, and xfstests is being
> inconsistent by insisting on the use of the fsck driver, but not using
> the mkfs driver.
>
> But that being said, hacking xfstests is not hard, and if Dave and/or
> Eric feels strongly about resisting this change, it's not worth a lot
> of time, one way or another....
I think we just want to make sure we understand the reasons for a change.
Every change has risks, and xfstests is used on a lot of different systems.
If I don't fully understand the motivation for a change, I ask questions.
All part of a careful review.
And I apologize for the mkfs vs. fsck inconsistency, that was probably
my fault, originally ;)
-Eric
> - Ted
On Fri, Jun 3, 2011 at 3:36 AM, Ted Ts'o <[email protected]> wrote:
> On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote:
>> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
>> > I don't really mind adding ext4dev to FSTYP case statements, it
>> > -is- something which blkid could, in theory, still return, and
>> > making xfstests cope with that and try to invoke fsck -t ext4dev
>> > doesn't bother me too much. ?It is sadly an fs type embedded into
>> > a few tools.
>>
>> I'm perfectly OK with using ext4dev as a filesystem type that allows testing
>> changes to ext4 on a system that is already running ext4 as the root fs.
>
> My take on this is that way too much time has been spent this subject.
No doubt.
> Being able to use ext4dev is useful, and given that we have all of
> this support in our existing system tools, why not use it to make ext4
> development more efficient/easy? ?As a bonus you can build the ext4dev
> as a module, and that means you the compile/edit/debug cycle can be
> much faster since you can avoid doing a reboot, for those
> circumstances where using KVM is not possible/convenient. ?Personally,
> I normally use KVM these days, but I can imagine situations where
> using ext4dev would be a better way to go. ?For example, I'd probably
> use KVM on my laptop, but for testing on production servers in a data
> center, I'd probably use ext4dev, for a variety of local deployment
> considerations that's not worth going into here.
>
> That being said, whether or not we modify xfstests seems to be a moot
> point. ?In order for me to do my bigalloc development, I've been
> patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and
> "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". ?It's a 3 line change. ?Not
> a big deal. ?I've been making this change using /bin/ed after
> installing xfstests. ?So if the XFS folks want to veto this change ---
> who cares? ?It's not hard to make the change locally in order to make
> xfstests.
>
> On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't
> see why it's so important that it clings to "fsck -t $FSTYP" instead
> of using "fsck.$FSTYP". ?There's no real benefit to calling the fsck
> driver; it's just an extra fork and exec, and xfstests is being
> inconsistent by insisting on the use of the fsck driver, but not using
> the mkfs driver.
>
> But that being said, hacking xfstests is not hard, and if Dave and/or
> Eric feels strongly about resisting this change, it's not worth a lot
> of time, one way or another....
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Ted
>
I blame only myself for not presenting the case correctly.
I made it sound like I am trying to push my own private hack upstream.
Actually, all 10 people involved in snapshot development clone my xfstests
tree from github, so we have no real need for the upstream change.
The reason I was pushing upstream is because I found this feature
so useful, I thought other developers may enjoy it as well.
Anyone on on this thread not having used ext4dev by next LSF
can come to me to claim his beer ;-)
Amir.
On 6/2/11 11:59 PM, Amir G. wrote:
> On Fri, Jun 3, 2011 at 3:36 AM, Ted Ts'o <[email protected]> wrote:
>> On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote:
>>> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
>>>> I don't really mind adding ext4dev to FSTYP case statements, it
>>>> -is- something which blkid could, in theory, still return, and
>>>> making xfstests cope with that and try to invoke fsck -t ext4dev
>>>> doesn't bother me too much. It is sadly an fs type embedded into
>>>> a few tools.
>>>
>>> I'm perfectly OK with using ext4dev as a filesystem type that allows testing
>>> changes to ext4 on a system that is already running ext4 as the root fs.
>>
>> My take on this is that way too much time has been spent this subject.
>
> No doubt.
>
>> Being able to use ext4dev is useful, and given that we have all of
>> this support in our existing system tools, why not use it to make ext4
>> development more efficient/easy? As a bonus you can build the ext4dev
>> as a module, and that means you the compile/edit/debug cycle can be
>> much faster since you can avoid doing a reboot, for those
>> circumstances where using KVM is not possible/convenient. Personally,
>> I normally use KVM these days, but I can imagine situations where
>> using ext4dev would be a better way to go. For example, I'd probably
>> use KVM on my laptop, but for testing on production servers in a data
>> center, I'd probably use ext4dev, for a variety of local deployment
>> considerations that's not worth going into here.
>>
>> That being said, whether or not we modify xfstests seems to be a moot
>> point. In order for me to do my bigalloc development, I've been
>> patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and
>> "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". It's a 3 line change. Not
>> a big deal. I've been making this change using /bin/ed after
>> installing xfstests. So if the XFS folks want to veto this change ---
>> who cares? It's not hard to make the change locally in order to make
>> xfstests.
>>
>> On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't
>> see why it's so important that it clings to "fsck -t $FSTYP" instead
>> of using "fsck.$FSTYP". There's no real benefit to calling the fsck
>> driver; it's just an extra fork and exec, and xfstests is being
>> inconsistent by insisting on the use of the fsck driver, but not using
>> the mkfs driver.
>>
>> But that being said, hacking xfstests is not hard, and if Dave and/or
>> Eric feels strongly about resisting this change, it's not worth a lot
>> of time, one way or another....
>>
>> - Ted
>>
>
> I blame only myself for not presenting the case correctly.
> I made it sound like I am trying to push my own private hack upstream.
> Actually, all 10 people involved in snapshot development clone my xfstests
> tree from github, so we have no real need for the upstream change.
> The reason I was pushing upstream is because I found this feature
> so useful, I thought other developers may enjoy it as well.
>
> Anyone on on this thread not having used ext4dev by next LSF
> can come to me to claim his beer ;-)
mmm I like beer, I'll see you then! ;)
-Eric (tucking this email away for future reference... ;)
> Amir.
On Fri, Jun 3, 2011 at 8:06 AM, Eric Sandeen <[email protected]> wrote:
> On 6/2/11 11:59 PM, Amir G. wrote:
>> On Fri, Jun 3, 2011 at 3:36 AM, Ted Ts'o <[email protected]> wrote:
>>> On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote:
>>>> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
>>>>> I don't really mind adding ext4dev to FSTYP case statements, it
>>>>> -is- something which blkid could, in theory, still return, and
>>>>> making xfstests cope with that and try to invoke fsck -t ext4dev
>>>>> doesn't bother me too much. ?It is sadly an fs type embedded into
>>>>> a few tools.
>>>>
>>>> I'm perfectly OK with using ext4dev as a filesystem type that allows testing
>>>> changes to ext4 on a system that is already running ext4 as the root fs.
>>>
>>> My take on this is that way too much time has been spent this subject.
>>
>> No doubt.
>>
>>> Being able to use ext4dev is useful, and given that we have all of
>>> this support in our existing system tools, why not use it to make ext4
>>> development more efficient/easy? ?As a bonus you can build the ext4dev
>>> as a module, and that means you the compile/edit/debug cycle can be
>>> much faster since you can avoid doing a reboot, for those
>>> circumstances where using KVM is not possible/convenient. ?Personally,
>>> I normally use KVM these days, but I can imagine situations where
>>> using ext4dev would be a better way to go. ?For example, I'd probably
>>> use KVM on my laptop, but for testing on production servers in a data
>>> center, I'd probably use ext4dev, for a variety of local deployment
>>> considerations that's not worth going into here.
>>>
>>> That being said, whether or not we modify xfstests seems to be a moot
>>> point. ?In order for me to do my bigalloc development, I've been
>>> patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and
>>> "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". ?It's a 3 line change. ?Not
>>> a big deal. ?I've been making this change using /bin/ed after
>>> installing xfstests. ?So if the XFS folks want to veto this change ---
>>> who cares? ?It's not hard to make the change locally in order to make
>>> xfstests.
>>>
>>> On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't
>>> see why it's so important that it clings to "fsck -t $FSTYP" instead
>>> of using "fsck.$FSTYP". ?There's no real benefit to calling the fsck
>>> driver; it's just an extra fork and exec, and xfstests is being
>>> inconsistent by insisting on the use of the fsck driver, but not using
>>> the mkfs driver.
>>>
>>> But that being said, hacking xfstests is not hard, and if Dave and/or
>>> Eric feels strongly about resisting this change, it's not worth a lot
>>> of time, one way or another....
>>>
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Ted
>>>
>>
>> I blame only myself for not presenting the case correctly.
>> I made it sound like I am trying to push my own private hack upstream.
>> Actually, all 10 people involved in snapshot development clone my xfstests
>> tree from github, so we have no real need for the upstream change.
>> The reason I was pushing upstream is because I found this feature
>> so useful, I thought other developers may enjoy it as well.
>>
>> Anyone on on this thread not having used ext4dev by next LSF
>> can come to me to claim his beer ;-)
>
> mmm I like beer, I'll see you then! ?;)
>
> -Eric (tucking this email away for future reference... ;)
>
Well, if anyone doesn't like beer, here are my low-tech ext4dev clone
scripts ;-)
ext4: scripts to clone and build ext4dev fs with default config options
diff --git a/clone_ext4dev.sh b/clone_ext4dev.sh
new file mode 100755
index 0000000..b5ae2c4
--- /dev/null
+++ b/clone_ext4dev.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+rm -rf fs/ext4dev
+mkdir -p fs/ext4dev
+cp -a fs/ext4/*.h fs/ext4dev
+cp -a fs/ext4/*.c fs/ext4dev
+cp -a fs/ext4/Kconfig fs/ext4dev
+cp -a fs/ext4/Makefile fs/ext4dev
+cp -a include/trace/events/ext4.h fs/ext4dev/ext4dev_events.h
+cd fs/ext4dev
+rm *.mod.c 2>/dev/null
+mv ext4_extents.h ext4dev_extents.h
+mv ext4_jbd2.h ext4dev_jbd2.h
+mv ext4_jbd2.c ext4dev_jbd2.c
+mv ext4.h ext4dev.h
+sed -f ../../ext4dev.sed -i *
+cd ..
+tar cfz ../ext4dev_module.tar.gz ext4dev/
diff --git a/ext4dev.sed b/ext4dev.sed
new file mode 100644
index 0000000..2ec2761
--- /dev/null
+++ b/ext4dev.sed
@@ -0,0 +1,3 @@
+s/ext4/ext4dev/g
+s/Ext4/Ext4dev/g
+s/EXT4/EXT4DEV/g
diff --git a/make_ext4dev.sh b/make_ext4dev.sh
new file mode 100755
index 0000000..495929f
--- /dev/null
+++ b/make_ext4dev.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+KERNEL=$(uname -r)
+KDIR=/lib/modules/${KERNEL}/build
+
+sudo cp fs/ext4dev/ext4dev_events.h ${KDIR}/include/trace/events/ext4dev.h
+make -C ${KDIR} M=${PWD}/fs/ext4dev modules
+sudo make -C ${KDIR} M=${PWD}/fs/ext4dev modules_install
+sudo rmmod ext4dev
+sudo modprobe ext4dev
+
diff --git a/fs/ext4/Makefile b/fs/ext4/Makefile
index c947e36..9981306 100644
--- a/fs/ext4/Makefile
+++ b/fs/ext4/Makefile
@@ -2,6 +2,13 @@
# Makefile for the linux ext4-filesystem routines.
#
+ifndef CONFIG_EXT4_FS
+CONFIG_EXT4_FS?=m
+CONFIG_EXT4_FS_XATTR?=y
+CONFIG_EXT4_FS_POSIX_ACL?=$(CONFIG_FS_POSIX_ACL)
+CONFIG_EXT4_FS_SECURITY?=y
+endif
+
obj-$(CONFIG_EXT4_FS) += ext4.o
ext4-y := balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o page-io.o \
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 3aa0b72..657d437 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -33,6 +33,18 @@
#include <linux/compat.h>
#endif
+#ifndef EXT4_SUPER_MAGIC
+#define EXT4_SUPER_MAGIC EXT3_SUPER_MAGIC
+/* configuration options for standalone module */
+#define CONFIG_EXT4_DEFAULTS_TO_ORDERED
+#define CONFIG_EXT4_FS_XATTR
+#ifdef CONFIG_FS_POSIX_ACL
+#define CONFIG_EXT4_FS_POSIX_ACL
+#endif
+#define CONFIG_EXT4_FS_SECURITY
+#define CONFIG_EXT4_DEBUG
+#endif
+
/*
* The fourth extended filesystem constants/structures
*/
---