RFC xfsprogs: try to handle mkfs of a file on 4k sector device
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 2 patches 2 repliesIn review
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Christoph Hellwig | Brian Foster |
|---|---|---|
| Series | R-b | R-b R-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/2, RFC] xfsprogs: try to handle mkfs of a file on 4k sector device
Today if you mkfs.xfs <filename> where the file resides on a hard-4k filesystem, we fail because it tries to do 512 direct IO when 4k is required; this is a bit cryptic:
# mkfs.xfs -f mnt/fsfile
meta-data=mnt/fsfile isize=256 agcount=4, agsize=8192 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0
data = bsize=4096 blocks=32768, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=853, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
existing superblock read failed: Invalid argument
mkfs.xfs: pwrite64 failed: Invalid argumentWe can modify platform_findsizes() to use the fsgeom call to get the "sector size" which should be used here, and warn that mismatches might exist if it fails.
This does mean there'll be a new warning emitted on fs images hosted on non-xfs filesystems; I'm not really quite sure it's worth it, hence the RFC nature of this lightly tested 2-patch series...
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs