http://oss.sgi.com/bugzilla/show_bug.cgi?id=734
Summary: mkfs.xfs fails for non-default sector size
Product: Linux XFS
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P2
Component: xfsprogs
AssignedTo: xfs-master@xxxxxxxxxxx
ReportedBy: andreas@xxxxxxxxx
mkfs.xfs from newer xfsprogs fails to create a filesystem with a non-default
sector size under Linux.
Linux kernel version: 2.4.34
glibc version: 2.3.6
everything was compiled with gcc 3.3.4
Platform: standard x86, 32 bit
The problem was reproduced in various systems.
With mkfs.xfs from xfsprogs-2.7.11 the follwoign command works fine:
root@test6:/net/orwell/work/xfsprogs-2.7.11/mkfs {85} $ ./mkfs.xfs -f -s
size=4096 /dev/scsi/host0/bus0/target1/lun0/part1
meta-data=/dev/scsi/host0/bus0/target1/lun0/part1 isize=256 agcount=8,
agsize=262059 blks
= sectsz=4096 attr=0
data = bsize=4096 blocks=2096472, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks
realtime =none extsz=65536 blocks=0, rtextents=0
With mkfs.xfs from a newer xfsprogs I get the following:
root@test6:/net/orwell/work/xfsprogs-2.8.18/mkfs {88} $ ./mkfs.xfs -f -s
size=4096 /dev/scsi/host0/bus0/target1/lun0/part1
meta-data=/dev/scsi/host0/bus0/target1/lun0/part1 isize=256 agcount=8,
agsize=262059 blks
= sectsz=4096 attr=0
data = bsize=4096 blocks=2096472, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks
realtime =none extsz=4096 blocks=0, rtextents=0
mkfs.xfs: pwrite64 failed: Invalid argument
With the default sector size, even mkfs.xfs from xfsprogs-2.8.18 works:
root@test6:/net/orwell/work/xfsprogs-2.8.18/mkfs {89} $ ./mkfs.xfs -f -s
size=512 /dev/scsi/host0/bus0/target1/lun0/part1
meta-data=/dev/scsi/host0/bus0/target1/lun0/part1 isize=256 agcount=8,
agsize=262059 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=2096472, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=2560, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=4096 blocks=0, rtextents=0
With strace(8) you can easily see the difference between the two commands
with 4k sector size:
Working mkfs.xfs from xfsprogs-2.7.11:
[...]
open("/dev/scsi/host0/bus0/target1/lun0/part1", O_RDWR|O_EXCL|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 17), ...}) = 0
ioctl(4, BLKBSZSET, 0xbfffe278) = 0
fstat64(4, {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 17), ...}) = 0
ioctl(4, BLKGETSIZE64, 0xbfffe2b8) = 0
ioctl(4, BLKSSZGET, 0xbffff6e0) = 0
chdir("/root") = 0
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40127000
write(1, "meta-data=/dev/scsi/host0/bus0/t"..., 93) = 93
write(1, " = "..., 53) = 53
write(1, "data = "..., 73) = 73
write(1, " = "..., 73) = 73
write(1, "naming =version 2 "..., 46) = 46
write(1, "log =internal log "..., 69) = 69
write(1, " = "..., 59) = 59
write(1, "realtime =none "..., 68) = 68
gettimeofday({1168373702, 226879}, NULL) = 0
open("/dev/urandom", O_RDONLY) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getpid() = 957
getuid32() = 0
gettimeofday({1168373702, 228346}, NULL) = 0
gettimeofday({1168373702, 228391}, NULL) = 0
read(3, "\17\200|\223S\271\334\315\20~P\0313\364\215\33", 16) = 16
pwrite64(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
131072, 0) = 131072
pwrite64(4, "XFSB\0\0\20\0\0\0\0\0\0\37\375X\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096, 0) = 4096
pwrite64(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
131072, 8587028480) = 131072
[...]
Failing mkfs.xfs from xfsprogs-2.8.18:
open("/dev/scsi/host0/bus0/target1/lun0/part1", O_RDWR|O_EXCL|O_DIRECT|
O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 17), ...}) = 0
ioctl(4, BLKBSZSET, 0xbfffe430) = 0
fstat64(4, {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 17), ...}) = 0
ioctl(4, BLKGETSIZE64, 0xbfffe458) = 0
ioctl(4, BLKSSZGET, 0xbffff89c) = 0
chdir("/root") = 0
old_mmap(NULL, 2363392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4018c000
old_mmap(NULL, 2363392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x403cd000
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4060e000
write(1, "meta-data=/dev/scsi/host0/bus0/t"..., 93) = 93
write(1, " = "..., 53) = 53
write(1, "data = "..., 73) = 73
write(1, " = "..., 73) = 73
write(1, "naming =version 2 "..., 46) = 46
write(1, "log =internal log "..., 69) = 69
write(1, " = "..., 59) = 59
write(1, "realtime =none "..., 68) = 68
gettimeofday({1168373747, 528195}, NULL) = 0
open("/dev/urandom", O_RDONLY) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getpid() = 978
getuid32() = 0
gettimeofday({1168373747, 528445}, NULL) = 0
gettimeofday({1168373747, 528481}, NULL) = 0
read(3, "\233\236\321\24|I\273\1\35\364\3266\317\222\365u", 16) = 16
pwrite64(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
131072, 0) = -1 EINVAL (Invalid argument)
write(2, "mkfs.xfs: pwrite64 failed: Inval"..., 44) = 44
[...]
Note that the failing command opens the device file with flag O_DIRECT, but
the working command doesn't!
The manual page for write(2) has this to say for error EINVAL:
[...]
EINVAL fd is attached to an object which is unsuitable for writing; or the
file was opened with the O_DIRECT flag, and either the address specified in
buf, the value specified in count, or the current file offset is not suitably
aligned.
[...]
So, do we have an alignment problem here?
The O_DIRECT flag seems to be related to the following change in
xfsprogs-2.8.11 from 08 August 2006:
- Make many tools use direct I/O on Linux if the underlying
device supports it. Mainly for speeding up xfs_repair as
libxfs does its own internal metadata buffering now.
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|