4:32 p.m.
On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de> wrote:
On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV
wrote:
> A question I have is XFS worth it?
I have done some testing with RHEL 7 Beta which use XFS as a default file system.
I have to recorgnize, that the -r switch of the lvresize command doesn't cooperate
with xfs in oppoiste of ext4.
Where you growing or shrinking the fs, and was it mounted at the time, and what error did
you get? XFS doesn't support shrink, and only can be grown online. I'm pretty sure
lvresize -r supports xfs_growfs via fsadm.
Chris Murphy
4:40 p.m.
On Feb 27, 2014, at 3:32 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de> wrote:
> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote:
>> A question I have is XFS worth it?
>
> I have done some testing with RHEL 7 Beta which use XFS as a default file system.
>
> I have to recorgnize, that the -r switch of the lvresize command doesn't
cooperate
> with xfs in oppoiste of ext4.
Where you growing or shrinking the fs, and was it mounted at the time, and what error did
you get? XFS doesn't support shrink, and only can be grown online. I'm pretty sure
lvresize -r supports xfs_growfs via fsadm.
worksforme
Starting with a 10TB XFS volume, 5TB x 5 disk VG.
# lvresize -r -v --size 15T VG/LV
Finding volume group VG
Executing: fsadm --verbose check /dev/VG/LV
fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
fsadm: Skipping filesystem check for device "/dev/mapper/VG-LV" as the
filesystem is mounted on /mnt
fsadm failed: 3
Archiving volume group "VG" metadata (seqno 2).
Extending logical volume LV to 15.00 TiB
Loading VG-LV table (253:0)
Suspending VG-LV (253:0) with device flush
Resuming VG-LV (253:0)
Creating volume group backup "/etc/lvm/backup/VG" (seqno 3).
Logical volume LV successfully resized
Executing: fsadm --verbose resize /dev/VG/LV 16106127360K
fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
fsadm: Device "/dev/mapper/VG-LV" size is 16492674416640 bytes
fsadm: Parsing xfs_info "/mnt"
fsadm: Resizing Xfs mounted on "/mnt" to fill device
"/dev/mapper/VG-LV"
fsadm: Executing xfs_growfs /mnt
meta-data=/dev/mapper/VG-LV isize=256 agcount=10, agsize=268435455 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2684354550, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2684354550 to 4026531825
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VG-LV 15T 33M 15T 1% /mnt
However, I don't know what "fsadm failed: 3" means.
Chris Murphy
4:51 p.m.
So far my small of research shows it isn't that big of a problem. We should
look more into it thought.
On Feb 27, 2014 5:41 PM, "Chris Murphy" <lists(a)colorremedies.com> wrote:
On Feb 27, 2014, at 3:32 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
>
> On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de>
wrote:
>
>> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV
wrote:
>>> A question I have is XFS worth it?
>>
>> I have done some testing with RHEL 7 Beta which use XFS as a default
file
system.
>>
>> I have to recorgnize, that the -r switch of the lvresize command
doesn't cooperate
>> with xfs in oppoiste of ext4.
>
> Where you growing or shrinking the fs, and was it mounted at the time,
and
what error did you get? XFS doesn't support shrink, and only can be
grown online. I'm pretty sure lvresize -r supports xfs_growfs via fsadm.
worksforme
Starting with a 10TB XFS volume, 5TB x 5 disk VG.
# lvresize -r -v --size 15T VG/LV
Finding volume group VG
Executing: fsadm --verbose check /dev/VG/LV
fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
fsadm: Skipping filesystem check for device "/dev/mapper/VG-LV" as the
filesystem is mounted on /mnt
fsadm failed: 3
Archiving volume group "VG" metadata (seqno 2).
Extending logical volume LV to 15.00 TiB
Loading VG-LV table (253:0)
Suspending VG-LV (253:0) with device flush
Resuming VG-LV (253:0)
Creating volume group backup "/etc/lvm/backup/VG" (seqno 3).
Logical volume LV successfully resized
Executing: fsadm --verbose resize /dev/VG/LV 16106127360K
fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
fsadm: Device "/dev/mapper/VG-LV" size is 16492674416640 bytes
fsadm: Parsing xfs_info "/mnt"
fsadm: Resizing Xfs mounted on "/mnt" to fill device
"/dev/mapper/VG-LV"
fsadm: Executing xfs_growfs /mnt
meta-data=/dev/mapper/VG-LV isize=256 agcount=10,
agsize=268435455 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2684354550, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2684354550 to 4026531825
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VG-LV 15T 33M 15T 1% /mnt
However, I don't know what "fsadm failed: 3" means.
Chris Murphy
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5:02 p.m.
On 2/27/14, 4:40 PM, Chris Murphy wrote:
On Feb 27, 2014, at 3:32 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
>
> On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de> wrote:
>
>> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote:
>>> A question I have is XFS worth it?
>>
>> I have done some testing with RHEL 7 Beta which use XFS as a default file
system.
>>
>> I have to recorgnize, that the -r switch of the lvresize command doesn't
cooperate
>> with xfs in oppoiste of ext4.
>
> Where you growing or shrinking the fs, and was it mounted at the time, and what error
did you get? XFS doesn't support shrink, and only can be grown online. I'm pretty
sure lvresize -r supports xfs_growfs via fsadm.
worksforme
Starting with a 10TB XFS volume, 5TB x 5 disk VG.
# lvresize -r -v --size 15T VG/LV
Finding volume group VG
Executing: fsadm --verbose check /dev/VG/LV
fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
fsadm: Skipping filesystem check for device "/dev/mapper/VG-LV" as the
filesystem is mounted on /mnt
fsadm failed: 3
<snip>
However, I don't know what "fsadm failed: 3" means.
fsadm.sh:
if detect_mounted ; then
verbose "Skipping filesystem check for device \"$VOLUME\"
as the filesystem is mounted on $MOUNTED";
cleanup 3
fi
...
cleanup() {
...
exit ${1:-1}
}
the script exits with error "3" meaning, well, "3," I guess, when the
fs is mounted. Not the nicest error reporting IMHO :)
-Eric
5:04 p.m.
Haha! Error: stuff happened.
On Feb 27, 2014 6:02 PM, "Eric Sandeen" <sandeen(a)redhat.com> wrote:
On 2/27/14, 4:40 PM, Chris Murphy wrote:
>
> On Feb 27, 2014, at 3:32 PM, Chris Murphy <lists(a)colorremedies.com>
wrote:
>
>>
>> On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de>
wrote:
>>
>>> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV
wrote:
>>>> A question I have is XFS worth it?
>>>
>>> I have done some testing with RHEL 7 Beta which use XFS as a default
file system.
>>>
>>> I have to recorgnize, that the -r switch of the lvresize command
doesn't cooperate
>>> with xfs in oppoiste of ext4.
>>
>> Where you growing or shrinking the fs, and was it mounted at the time,
and what error did you get? XFS doesn't support shrink, and only can be
grown online. I'm pretty sure lvresize -r supports xfs_growfs via fsadm.
>
> worksforme
>
> Starting with a 10TB XFS volume, 5TB x 5 disk VG.
>
>
> # lvresize -r -v --size 15T VG/LV
> Finding volume group VG
> Executing: fsadm --verbose check /dev/VG/LV
> fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
> fsadm: Skipping filesystem check for device "/dev/mapper/VG-LV" as the
filesystem is mounted on /mnt
> fsadm failed: 3
<snip>
> However, I don't know what "fsadm failed: 3" means.
fsadm.sh:
if detect_mounted ; then
verbose "Skipping filesystem check for device \"$VOLUME\"
as the filesystem is mounted on $MOUNTED";
cleanup 3
fi
...
cleanup() {
...
exit ${1:-1}
}
the script exits with error "3" meaning, well, "3," I guess, when the
fs
is mounted. Not the nicest error reporting IMHO :)
-Eric
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2:33 a.m.
Dne 28.2.2014 00:02, Eric Sandeen napsal(a):
On 2/27/14, 4:40 PM, Chris Murphy wrote:
>
> On Feb 27, 2014, at 3:32 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
>
>>
>> On Feb 27, 2014, at 3:02 PM, Jochen Schmitt <Jochen(a)herr-schmitt.de>
wrote:
>>
>>> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote:
>>>> A question I have is XFS worth it?
>>>
>>> I have done some testing with RHEL 7 Beta which use XFS as a default file
system.
>>>
>>> I have to recorgnize, that the -r switch of the lvresize command doesn't
cooperate
>>> with xfs in oppoiste of ext4.
>>
>> Where you growing or shrinking the fs, and was it mounted at the time, and what
error did you get? XFS doesn't support shrink, and only can be grown online. I'm
pretty sure lvresize -r supports xfs_growfs via fsadm.
>
> worksforme
>
> Starting with a 10TB XFS volume, 5TB x 5 disk VG.
>
>
> # lvresize -r -v --size 15T VG/LV
> Finding volume group VG
> Executing: fsadm --verbose check /dev/VG/LV
> fsadm: "xfs" filesystem found on "/dev/mapper/VG-LV"
> fsadm: Skipping filesystem check for device "/dev/mapper/VG-LV" as the
filesystem is mounted on /mnt
> fsadm failed: 3
<snip>
> However, I don't know what "fsadm failed: 3" means.
fsadm.sh:
if detect_mounted ; then
verbose "Skipping filesystem check for device \"$VOLUME\"
as the filesystem is mounted on $MOUNTED";
cleanup 3
fi
...
cleanup() {
...
exit ${1:-1}
}
the script exits with error "3" meaning, well, "3," I guess, when the
fs is mounted. Not the nicest error reporting IMHO :)
man fsadm
DIAGNOSTICS
On successful completion, the status code is 0. A status code of 2
indicates the operation was interrupted by the user. A
status code of 3 indicates the requested check operation could not be
performed because the filesystem is mounted and does
not support an online fsck(8). A status code of 1 is used for other
failures.
Zdenek
7:37 a.m.
On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac <zkabelac(a)redhat.com> wrote:
>> fsadm failed: 3
man fsadm
DIAGNOSTICS
On successful completion, the status code is 0. A status code of 2 indicates the
operation was interrupted by the user. A
status code of 3 indicates the requested check operation could not be performed
because the filesystem is mounted and does
not support an online fsck(8). A status code of 1 is used for other failures.
Yeah but did fsadm fail? No, as a whole its operation succeeded. Can we say fsadm failed
to run fsck? I guess that's one way to look at it, but then it failed to understand it
shouldn't request a check operation on XFS in the first place.
Chris Murphy
7:54 a.m.
Dne 28.2.2014 14:37, Chris Murphy napsal(a):
On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac <zkabelac(a)redhat.com> wrote:
>>> fsadm failed: 3
>
> man fsadm
>
> DIAGNOSTICS
> On successful completion, the status code is 0. A status code of 2 indicates
the operation was interrupted by the user. A
> status code of 3 indicates the requested check operation could not be
performed because the filesystem is mounted and does
> not support an online fsck(8). A status code of 1 is used for other
failures.
Yeah but did fsadm fail? No, as a whole its operation succeeded. Can we say fsadm failed
to run fsck? I guess that's one way to look at it, but then it failed to understand it
shouldn't request a check operation on XFS in the first place.
Chris Murphy
Current logic of lvm is to call fsadm to check blockdevice (lvm2 knows
nothing about about filesystems).
fsadm translate this to check xfs - which is not supported by xfs (I've no
idea if there ever be support for this operation) - so fsadm reports it has
failed to do any check.
lvm2 detects through error code 3 that requested operation is not supported,
but considered safe to be ignore and continues.
Of course fsadm could return 0 - but then it wouldn't be able to recognize
if check really was made or just skipped.
This message is only shown in verbose mode - and it's mainly for developer to
know what has happened (or actually not happened)
Zdenek
8:12 a.m.
On 2/28/14, 7:54 AM, Zdenek Kabelac wrote:
Dne 28.2.2014 14:37, Chris Murphy napsal(a):
>
> On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac <zkabelac(a)redhat.com> wrote:
>
>
>>>> fsadm failed: 3
>>
>
>> man fsadm
>>
>> DIAGNOSTICS
>> On successful completion, the status code is 0. A status code of 2
indicates the operation was interrupted by the user. A
>> status code of 3 indicates the requested check operation could not be
performed because the filesystem is mounted and does
>> not support an online fsck(8). A status code of 1 is used for other
failures.
Ok, granted, I should have read the fsadm manpage. :)
> Yeah but did fsadm fail? No, as a whole its operation succeeded.
> Can we say fsadm failed to run fsck? I guess that's one way to look
> at it, but then it failed to understand it shouldn't request a
> check operation on XFS in the first place.
>
> Chris Murphy
>
Current logic of lvm is to call fsadm to check blockdevice (lvm2 knows nothing about
about filesystems).
fsadm translate this to check xfs - which is not supported by xfs
Well, it failed to check it because it is *mounted*, right? It said this:
> fsadm: Skipping filesystem check for device
"/dev/mapper/VG-LV" as the filesystem is mounted on /mnt
> fsadm failed: 3
extN does the same thing:
# e2fsck /dev/sdb3
e2fsck 1.41.12 (17-May-2010)
/dev/sdb3 is mounted.
e2fsck: Cannot continue, aborting.
# xfs_repair /dev/sdc4
xfs_repair: /dev/sdc4 contains a mounted filesystem
fatal error -- couldn't initialize XFS library
(I've no idea if there ever be support for this operation) - so
fsadm
reports it has failed to do any check.
xfs certainly does have check and repair tools - man xfs_repair.
You can run it with "-n" if you want check-only.
However, I see that (at leat my copy of) fsadm reqiures xfs_check,
which has been deprecated upstream in favor of xfs_repair -n.
xfs_check doesn't scale, and xfs_repair -n performs the same
tasks.
XFS_CHECK=xfs_check
so I guess I should file a bug on that.
lvm2 detects through error code 3 that requested operation is not
supported, but considered safe to be ignore and continues.
Of course fsadm could return 0 - but then it wouldn't be able to
recognize if check really was made or just skipped.
This message is only shown in verbose mode - and it's mainly for
developer to know what has happened (or actually not happened)
Ok, that's fair enough.
Thanks,
-Eric
Zdenek
8:14 a.m.
On 2/28/14, 8:12 AM, Eric Sandeen wrote:
However, I see that (at least my copy of) fsadm requires xfs_check,
which has been deprecated upstream in favor of xfs_repair -n.
xfs_check doesn't scale, and xfs_repair -n performs the same
tasks.
> XFS_CHECK=xfs_check
so I guess I should file a bug on that.
Sorry, I should have checked upstream, I see that upstream handles
absence of xfs_check.
"xfs") if which "$XFS_CHECK"
>"$NULL" 2>&1 ; then
dry "$XFS_CHECK" "$VOLUME"
else
# Replacement for outdated xfs_check
# FIXME: for small devices we need to force_geometry,
# since we run in '-n' mode, it shouldn't be
problem.
# Think about better way....
dry "$XFS_REPAIR" -n -o force_geometry
"$VOLUME"
fi ;;
TBH, I would just switch 100% to xfs_repair, rather than using
it as a fallback. We can talk about this offline though. :)
Thanks,
-Eric
8:14 a.m.
Dne 28.2.2014 15:12, Eric Sandeen napsal(a):
On 2/28/14, 7:54 AM, Zdenek Kabelac wrote:
> Dne 28.2.2014 14:37, Chris Murphy napsal(a):
>>
>> On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac <zkabelac(a)redhat.com> wrote:
>>
>>
>>>>> fsadm failed: 3
>>>
>>
>>> man fsadm
>>>
>>> DIAGNOSTICS
>>> On successful completion, the status code is 0. A status code of 2
indicates the operation was interrupted by the user. A
>>> status code of 3 indicates the requested check operation could not be
performed because the filesystem is mounted and does
>>> not support an online fsck(8). A status code of 1 is used for other
failures.
Ok, granted, I should have read the fsadm manpage. :)
>> Yeah but did fsadm fail? No, as a whole its operation succeeded.
>> Can we say fsadm failed to run fsck? I guess that's one way to look
>> at it, but then it failed to understand it shouldn't request a
>> check operation on XFS in the first place.
>>
>> Chris Murphy
>>
>
> Current logic of lvm is to call fsadm to check blockdevice (lvm2 knows nothing
about about filesystems).
>
> fsadm translate this to check xfs - which is not supported by xfs
Well, it failed to check it because it is *mounted*, right? It said this:
>> fsadm: Skipping filesystem check for device "/dev/mapper/VG-LV" as the
filesystem is mounted on /mnt
>> fsadm failed: 3
extN does the same thing:
# e2fsck /dev/sdb3
e2fsck 1.41.12 (17-May-2010)
/dev/sdb3 is mounted.
e2fsck: Cannot continue, aborting.
# xfs_repair /dev/sdc4
xfs_repair: /dev/sdc4 contains a mounted filesystem
fatal error -- couldn't initialize XFS library
> (I've no idea if there ever be support for this operation) - so fsadm
> reports it has failed to do any check.
xfs certainly does have check and repair tools - man xfs_repair.
You can run it with "-n" if you want check-only.
However, I see that (at leat my copy of) fsadm reqiures xfs_check,
which has been deprecated upstream in favor of xfs_repair -n.
xfs_check doesn't scale, and xfs_repair -n performs the same
tasks.
> XFS_CHECK=xfs_check
so I guess I should file a bug on that.
https://bugzilla.redhat.com/show_bug.cgi?id=1051871
Zdenek
3746
days inactive
3747
days old
10 comments
4 participants
participants (4)
-
Chris Murphy -
Eric Sandeen -
James Harshaw -
Zdenek Kabelac