Date: Sat, 9 Jun 2001 11:17:24 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: patl@Phoenix.Volant.ORG, Peter Wemm <peter@wemm.org>, FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] Message-ID: <200106091817.f59IHO108472@earth.backplane.com> References: <ML-3.4.992018636.5562.patl@asimov.phoenix.volant.org> <3B225E32.484672C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:It will _NOT_ work for cryptographic FS's, where the number
:of pages or the page boundaries change witing a file,
:compressing FS's, FS's with different block sizes (such as
:...
:-- Terry
Woa... sure it will! The VM Object is representing the
clear text file, not the actual underlying crypted file. So
it should work just fine.
Also, in the filespace the physical sector size is irrelevant.
Take the VN (now MD) device for example. If you use a file for
backing store the sector size from the point of view of the MD
device can be 512 bytes no matter what the actual sector size of
the filesystem backing the file is. But if you use, say, swap
for backing store the sector size from the point of view of
the MD device is one page (4K on IA32), period end of story.
Also, even in UFS the physical topology of a file varies... a
file might be partially represented by a fragment (e.g. 1K) as
well as a full file block (8K) in the physical topology. But
the VM Object representing the file doesn't know and doesn't care.
So VM Objects for files are 100% independant of the topology
of the filesystem backing those files. This means that the fixed
NULLFS should work just dandy for any filesystem. It may not be
able to overload devices transparently, but it should definitely
be able to overload a filesystem.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106091817.f59IHO108472>
