On m68k, with CONFIG_LBD=n: range of data type range of data type left/right = xfs_fsblock_t (32 or 64 bit), NULLDFSBNO = xfs_dfsbno_t (64 bit) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There
Hmm, can't reproduce it here with CONFIG_LBD=n on x86, but the following patch should fix it: Index: linux-2.6/fs/xfs/xfs_btree.c == -- linux-2.6.orig/fs/xfs/xfs_btree.c 2009-01-01 15:57:04.606547140
x86-32 or -64? It may also depend on the compiler version. I have gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). Yep, the warning is good. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -
repair is compromised without the second SB so we should fix mkfs too to prevent people from creating single AG filesystems. Christoph Hellwig wrote: Currently xfs_re
oser to the source of the bug. It's being detecting when reading in the buffer to do a left shift now, not during the delete of a record. I'd suggest that you treat th
y, it was for buffered IO's benefit on the rt subvol, to reduce unwritten extent conversion IIRC. I was going to follow up w/ the commit etc yesterday, but the mailing
speculative EOF allocation. That's what the BMAPI_SYNC flag does.... That being said, it can't truncate away pre-existing speculative allocations on other files, which
e of data type range of data type left/right = xfs_fsblock_t (32 or 64 bit), NULLDFSBNO = xfs_dfsbno_t (64 bit) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There
for that we'd need to get the generic freeze bits in first. Andrews, as they are in 2.6.28-rc2 do you plan to send them? Any chance for a general -mm merge plan, btw?
d on the compiler version. I have gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). Yep, the warning is good. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -