Hi,
I just noticed that the FS_REQUIRES_DEV flag is used for just two
things in the kernel.
1/ to place the text 'nodev' at the start of the line in
/proc/filesystems
2/ to tell nfsd that it is reasonably OK to use the s_dev field
in the superblock as a stable, unique identifier for the
filesystem.
I have a filesystem I am playing with for which I am quite happy to
lose the second aspect of FS_REQUIRES_DEV (it does use a device, but
there could well be multiple devices, and the fs can migrate from one
device to another so s_dev is even less stable than normal). However
I would like to understand the implications of losing the first aspect
of FS_REQUIRES_DEV before deciding whether to provide the flag or not.
Hence the question in the subject:
Who uses the 'nodev' flag in /proc/filesystems?
Are there any known users of this flag?
Thanks,
NeilBrown
>
>Hence the question in the subject:
>
> Who uses the 'nodev' flag in /proc/filesystems?
>
>Are there any known users of this flag?
>
pam_mount. If a specific filesystem is nodev, --bind or --move, fsck is
skipped. If you want to change /proc/filesystems, you can do so as long as
you provide an alternative ;) Does not need to be stable, as
/proc/filesystems is only used when a volume is initially mounted in
pam_mount.
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
On Sunday March 19, [email protected] wrote:
> >
> >Hence the question in the subject:
> >
> > Who uses the 'nodev' flag in /proc/filesystems?
> >
> >Are there any known users of this flag?
> >
>
> pam_mount. If a specific filesystem is nodev, --bind or --move, fsck is
> skipped. If you want to change /proc/filesystems, you can do so as long as
> you provide an alternative ;) Does not need to be stable, as
> /proc/filesystems is only used when a volume is initially mounted in
> pam_mount.
Pam_mount .. (google...) you learn something new every day, don't you!
That sounds like a reasonable usage of 'nodev', though testing for
/sbin/fsck.$FSTYPE might do as well...
I guess in my case I could live without the auto-fsck, and as there
isn't necessarily just one device to take part in the fsck, it might
be awkward anyway.
Thanks.
I wonder if there are any others....
NeilBrown
>Pam_mount .. (google...) you learn something new every day, don't you!
>
>That sounds like a reasonable usage of 'nodev', though testing for
>/sbin/fsck.$FSTYPE might do as well...
>
Quite good idea, and it would make pam_mount more portable. I'll add that
to my todo list. :)
I wonder if there is a filesystem that is nodev, but has fsck.
Jan Engelhardt
--
On 3/20/06, Jan Engelhardt <[email protected]> wrote:
>
> I wonder if there is a filesystem that is nodev, but has fsck.
>
>
> Jan Engelhardt
> --
If a filesystem is nodev, then what would you fsck? Am i missing something?
On Mon, Mar 20, 2006 at 01:17:59PM -0300, Matheus Izvekov wrote:
> If a filesystem is nodev, then what would you fsck? Am i missing something?
There's a UML filesystem for which the nodev-implies-no-fsck behavior
is inconvenient. It stores its files as files on the host, where the
file metadata is stored separately from the file data. If the two
fall out of sync after a crash, we need to fsck it. In this case,
fsck would do a hostfs mount of the data and metadata (where the files
are available as they exist on the host) and fix things up.
So, in this case, the thing being fscked is a directory hierarchy on
the host.
Jeff
On 3/20/06, Jeff Dike <[email protected]> wrote:
> On Mon, Mar 20, 2006 at 01:17:59PM -0300, Matheus Izvekov wrote:
> > If a filesystem is nodev, then what would you fsck? Am i missing something?
>
> There's a UML filesystem for which the nodev-implies-no-fsck behavior
> is inconvenient. It stores its files as files on the host, where the
> file metadata is stored separately from the file data. If the two
> fall out of sync after a crash, we need to fsck it. In this case,
> fsck would do a hostfs mount of the data and metadata (where the files
> are available as they exist on the host) and fix things up.
>
> So, in this case, the thing being fscked is a directory hierarchy on
> the host.
>
> Jeff
>
I see, i didnt know about this. But then pam_mount would need to do
special treatment for this. I imagine it has been only coded to work
in the case where there is a device to pass to fsck as a parameter.
On Mon, Mar 20, 2006 at 04:22:51PM -0300, Matheus Izvekov wrote:
> I see, i didnt know about this. But then pam_mount would need to do
> special treatment for this. I imagine it has been only coded to work
> in the case where there is a device to pass to fsck as a parameter.
Yeah, I don't doubt it. I was just commenting on the nodev aspect of this.
Jeff
>> I see, i didnt know about this. But then pam_mount would need to do
>> special treatment for this. I imagine it has been only coded to work
>> in the case where there is a device to pass to fsck as a parameter.
>
>Yeah, I don't doubt it. I was just commenting on the nodev aspect of this.
>
But hey, when hostfs is nodev-but-fsckable, then looking for /sbin/fsck.XYZ
is even better than reading /proc/filesystems...
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
Neil Brown <[email protected]> writes:
> Hence the question in the subject:
>
> Who uses the 'nodev' flag in /proc/filesystems?
>
> Are there any known users of this flag?
mount is using it, when no explicit type is specified. When iterating
over /proc/filesystems it ignores lines with the nodev flag.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Mon, Mar 20, 2006 at 08:58:58PM +0100, Jan Engelhardt wrote:
> But hey, when hostfs is nodev-but-fsckable, then looking for /sbin/fsck.XYZ
> is even better than reading /proc/filesystems...
It's humfs, BTW (hostfs consistency is maintained by the host), but yes.
Jeff
>
>On Mon, Mar 20, 2006 at 08:58:58PM +0100, Jan Engelhardt wrote:
>> But hey, when hostfs is nodev-but-fsckable, then looking for /sbin/fsck.XYZ
>> is even better than reading /proc/filesystems...
>
>It's humfs, BTW (hostfs consistency is maintained by the host), but yes.
>
humm. Hm! Calls for buzzfs. :)
Jan Engelhardt
--