FIBMAP ioctl missing

FIBMAP ioctl missing

[dexen deVries]

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

[[[↓][→]]]

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIBMAP ioctl missing

[Jérôme Poulin]

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.

Envoyé de mon appareil mobile.

Jérôme Poulin
Solutions G.A.

On 2011-02-24, at 17:34, dexen deVries <dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> 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
>
> [[[↓][→]]]
>
>> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIBMAP ioctl missing

[dexen deVries]

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.

Regards,
-- 
dexen deVries

[[[↓][→]]]

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIBMAP ioctl missing

[Ryusuke Konishi]

On Fri, 25 Feb 2011 09:02:46 +0100, dexen deVries wrote:
> 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.

Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIBMAP ioctl missing

[dexen deVries]

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.
> 
> 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. 


> 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?

-- 
dexen deVries

[[[↓][→]]]

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIBMAP ioctl missing

[Ryusuke Konishi]

(Cc'ed to linux-nilfs)
On Fri, 25 Feb 2011 12:44:06 +0100, dexen deVries wrote:
> 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.
> > 
> > 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. 

Thanks for the information.  This actually worked on nilfs.

> > 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.

Sounds a good idea.
 
> 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?

Only GC routine can move data and metadata, and only nilfs_cleanerd
triggers the routine.  Nilfs freezes past data and namespace into
snapshot without copying or moving blocks.

nilfs_cleanerd (NILFS GC) moves blocks per segment not per file, so
pinning files would be achieved by skipping reclamation of segments
recording the pinned files.

Thanks,
Ryusuke Konishi

> -- 
> dexen deVries
> 
> [[[↓][→]]]
> 
> > 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html