FIBMAP ioctl missing

how does a C compiler get to be that big? what is all that code doing?

Hello,

as NILFS2 doesn't implement the FIBMAP ioctl, LILO cannot be used on it. I've just learned about it the hard way -- after migrating computer's only filesystem to NILFS2, running LILO returns:
ioctl FIBMAP: Invalid argument

I see the FS_IOC_FIEMAP is implemented; perhaps some wrapper around could be used to provide FIBMAP as well?

Regards,
--
dexen deVries

[[[↓][→]]]

Quoted 1 line

how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Just thinking about it fast, NILFS2 is a filesystem that wraps around the disk forever and LILO writes a bitmap of where the kernel image is. So if NILFS moves the image then LILO is at lost and will load some data which is not the kernel instead. A fast guess I would say using LILO on NILFS is impossible by design.

how does a C compiler get to be that big? what is all that code doing?

Quoted 5 lines · On Friday 25 of February 2011 01:21:53 you wrote:

Just thinking about it fast, NILFS2 is a filesystem that wraps around the disk forever and LILO writes a bitmap of where the kernel image is. So if NILFS moves the image then LILO is at lost and will load some data which is not the kernel instead. A fast guess I would say using LILO on NILFS is impossible by design.

That's a good point, thanks.

A dirty hack comes to my mind, back from the days of DOS: files marked with `system' attribute were not moved during defrag (important for io.sys & msdos.sys). Perhaps using some sensible attribute (i? t? a new one?) would prevent nilfs_cleanerd from moving the file?

Would require implementing attributes on NILFS, thou.

I guess pinning files on the device is possible in some way. But Supporting FIBMAP, which internally means supporting iops->bmap vfs interface, sounds more delicate than FIEMAP because it is actually used to determine block location for raw-write access. The swapfile is an example of that.

Strictly, FIEMAP has the same risk, but in practice, we are using it for more harmless purposes such like analyzing fragmentation or giving hint to read-ahead tools.

If we can safely disable a swapfile on filesystem and we can widely share the basic premise that "writing to the block location acquired by FIBMAP is a very dangerous thing for log-structured filesystems or COW filesystems", we could add it.

how does a C compiler get to be that big? what is all that code doing?

Quoted 6 lines · On Friday 25 of February 2011 12:34:23 you wrote:

I guess pinning files on the device is possible in some way. But Supporting FIBMAP, which internally means supporting iops->bmap vfs interface, sounds more delicate than FIEMAP because it is actually used to determine block location for raw-write access. The swapfile is an example of that.

Quoted 3 lines

Strictly, FIEMAP has the same risk, but in practice, we are using it for more harmless purposes such like analyzing fragmentation or giving hint to read-ahead tools.

As a sidenote, it seems hdparm has that `--fibmap' subcommand, but it actually issues FIEMAP rather than FIBMAP ioctl.

Quoted 4 lines

If we can safely disable a swapfile on filesystem and we can widely share the basic premise that "writing to the block location acquired by FIBMAP is a very dangerous thing for log-structured filesystems or COW filesystems", we could add it.

Perhaps it would be enough if FIBMAP implementation for NILFS checked if the file has a `pin-it-down' attribute and only then returned anything other than EINVAL.

Regarding pinning a file to physical location on a device: if a file is part of a snapshot, does its data or metadata ever get moved?

Signature · 3 lines

dexen deVries

[[[↓][→]]]

Quoted 1 line

how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90