--432202577-1418353879-943851834=:5696
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 26 Nov 1999, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, 25 Nov 1999 06:17:39 +0100 (CET), Mike Galbraith
> <mikeg@weiden.de> said:
>
> > The way I see it, the ramdisk used to work by making it's data persistent
> > in the buffer cache. Today, data doesn't live in the buffer cache, it
> > lives in the page cache. Ergo, the task at hand is to figure out how
> > to make data in the page cache persistent rather than copying that data
> > back and forth.
>
> No. It needs to do more than just behave as an in-memory filesystem: it
> needs to behave like a block device. That means that buffer cache
> aliases of page cache data still need to work: you need to be able to
> run dump or fsck on the ramdisk of a mounted filesystem, for example.
> Using a ramdisk to test fs utilities is a legitimate use, and if you
> move the ramdisk out of the buffer cache it will just break this (as
> well as polluting the page cache semantics).
Thanks for the reply Stephen.
(when I said I'd taken the ramdisk out of the buffer cache, I meant only
the persistent data.. copied that unconditionally to/from vmalloc'd area
instead of pegging down buffers. works fine but is slooo)
The attached against 2.3.28 is faster, but I _hate_ the copy on write.
I tried (like hell) to avoid it by looking to see if a stale buffer
existed, bforget() the old data and peg down the new data. That didn't
work worth spit (corruption/oops/OOM/hardlock/softlock.. pick one:) and
I wish I knew why.
For blocksize = PAGE_SIZE ramdisks, I _think_ I could avoid the copy by
keeping track of allocated blocks and when a write request comes in do
something like..
if (block_table[blk] != request_bh->b_page) {
if (block_table[blk])
put_page(block_table[blk]);
get_page(request_bh->b_page);
block_table[blk] = request_bh->b_page;
}
..and only (always) have to copy out for a read. Trouble is, it could
only work for 4k blocksize.. and is probably pretty gross.
(so off we go to filemap.c..)
What I'd like to do is to set up an address space (still have to figure
out exactly howto.. swap_state.c) and use page cache functions to map
and unmap the incoming data into the ramdisk's address space. Trouble
is, it looks like a page can only be in one address space.. correct?
Is it possible to use page cache functionality to do correctly what
the above pseudo code tries to accomplish? If so, a subtle hint (and
maybe a 2x4 to rub it in with) would be much appreciated.
TIA for any advice,
-Mike
--432202577-1418353879-943851834=:5696
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xx
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.Linu.4.10.9911290603540.5696@mikeg.weiden.de>
Content-Description:
Content-Disposition: attachment; filename=xx
LS0tIGRyaXZlcnMvYmxvY2svcmQuYy5vcmcJU3VuIE9jdCAzMSAwNTo1Nzoy
OSAxOTk5DQorKysgZHJpdmVycy9ibG9jay9yZC5jCU1vbiBOb3YgMjkgMDM6
NDk6NDUgMTk5OQ0KQEAgLTk1LDggKzk1LDggQEANCiANCiBzdGF0aWMgdW5z
aWduZWQgbG9uZyByZF9sZW5ndGhbTlVNX1JBTURJU0tTXTsJLyogU2l6ZSBv
ZiBSQU0gZGlza3MgaW4gYnl0ZXMgICAqLw0KIHN0YXRpYyBpbnQgcmRfaGFy
ZHNlY1tOVU1fUkFNRElTS1NdOwkJLyogU2l6ZSBvZiByZWFsIGJsb2NrcyBp
biBieXRlcyAqLw0KLXN0YXRpYyBpbnQgcmRfYmxvY2tzaXplc1tOVU1fUkFN
RElTS1NdOwkJLyogU2l6ZSBvZiAxMDI0IGJ5dGUgYmxvY2tzIDopICAqLw0K
LXN0YXRpYyBpbnQgcmRfa2JzaXplW05VTV9SQU1ESVNLU107CQkvKiBTaXpl
IGluIGJsb2NrcyBvZiAxMDI0IGJ5dGVzICovDQorc3RhdGljIGludCByZF9i
bG9ja3NpemVzW05VTV9SQU1ESVNLU107CQkvKiBTaXplIG9mIGxvZ2ljYWwg
YmxvY2tzIGluIGJ5dGVzKi8NCitzdGF0aWMgaW50IHJkX2tic2l6ZVtOVU1f
UkFNRElTS1NdOwkJLyogU2l6ZSBvZiBkZXZpY2UgaW4gS0IgKi8NCiANCiAv
Kg0KICAqIFBhcmFtZXRlcnMgZm9yIHRoZSBib290LWxvYWRpbmcgb2YgdGhl
IFJBTSBkaXNrLiAgVGhlc2UgYXJlIHNldCBieQ0KQEAgLTEwNCwxOSArMTA0
LDggQEANCiAgKiBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgc2V0dXAgcm91dGlu
ZSAoZnJvbSB0aGUgc3RvcmVkIGJvb3Qgc2VjdG9yDQogICogaW5mb3JtYXRp
b24pLiANCiAgKi8NCi1pbnQgcmRfc2l6ZSA9IDQwOTY7CQkvKiBTaXplIG9m
IHRoZSBSQU0gZGlza3MgKi8NCi0vKg0KLSAqIEl0IHdvdWxkIGJlIHZlcnkg
ZGVzaWRlcmFibGUgdG8gaGF2ZSBhIHNvZnQtYmxvY2tzaXplICh0aGF0IGlu
IHRoZSBjYXNlDQotICogb2YgdGhlIHJhbWRpc2sgZHJpdmVyIGlzIGFsc28g
dGhlIGhhcmRibG9ja3NpemUgOykgb2YgUEFHRV9TSVpFIGJlY2F1c2UNCi0g
KiBkb2luZyB0aGF0IHdlJ2xsIGFjaGlldmUgYSBmYXIgYmV0dGVyIE1NIGZv
b3RwcmludC4gVXNpbmcgYSByZF9ibG9ja3NpemUgb2YNCi0gKiBCTE9DS19T
SVpFIGluIHRoZSB3b3JzdCBjYXNlIHdlJ2xsIG1ha2UgUEFHRV9TSVpFL0JM
T0NLX1NJWkUgYnVmZmVyLXBhZ2VzDQotICogdW5mcmVlYWJsZS4gV2l0aCBh
IHJkX2Jsb2Nrc2l6ZSBvZiBQQUdFX1NJWkUgaW5zdGVhZCB3ZSBhcmUgc3Vy
ZSB0aGF0IG9ubHkNCi0gKiAxIHBhZ2Ugd2lsbCBiZSBwcm90ZWN0ZWQuIERl
cGVuZGluZyBvbiB0aGUgc2l6ZSBvZiB0aGUgcmFtZGlzayB5b3UNCi0gKiBt
YXkgd2FudCB0byBjaGFuZ2UgdGhlIHJhbWRpc2sgYmxvY2tzaXplIHRvIGFj
aGlldmUgYSBiZXR0ZXIgb3Igd29yc2UgTU0NCi0gKiBiZWhhdmlvdXIuIFRo
ZSBkZWZhdWx0IGlzIHN0aWxsIEJMT0NLX1NJWkUgKG5lZWRlZCBieSByZF9s
b2FkX2ltYWdlIHRoYXQNCi0gKiBzdXBwb3NlcyB0aGUgZmlsZXN5c3RlbSBp
biB0aGUgaW1hZ2UgdXNlcyBhIEJMT0NLX1NJWkUgYmxvY2tzaXplKS4NCi0g
Ki8NCi1pbnQgcmRfYmxvY2tzaXplID0gQkxPQ0tfU0laRTsJLyogU2l6ZSBv
ZiB0aGUgUkFNIGRpc2tzICovDQoraW50IHJkX3NpemUgPSA0MDk2OwkJLyog
RGVmYXVsdCBzaXplIG9mIHRoZSBSQU0gZGlza3MgKi8NCitpbnQgcmRfYmxv
Y2tzaXplID0gQkxPQ0tfU0laRTsJLyogRGVmYXVsdCBibG9ja3NpemUgb2Yg
dGhlIFJBTSBkaXNrcyAqLw0KIA0KICNpZm5kZWYgTU9EVUxFDQogDQpAQCAt
MTY3LDExICsxNTYsMTggQEANCiAJcmV0dXJuIHJhbWRpc2tfc2l6ZShzdHIp
Ow0KIH0NCiANCitzdGF0aWMgaW50IF9faW5pdCByYW1kaXNrX2Jsb2Nrc2l6
ZShjaGFyICpzdHIpDQorew0KKwlyZF9ibG9ja3NpemUgPSBzaW1wbGVfc3Ry
dG9sKHN0cixOVUxMLDApOw0KKwlyZXR1cm4gMTsNCit9DQorDQogX19zZXR1
cCgicmFtZGlza19zdGFydD0iLCByYW1kaXNrX3N0YXJ0X3NldHVwKTsNCiBf
X3NldHVwKCJsb2FkX3JhbWRpc2s9IiwgbG9hZF9yYW1kaXNrKTsNCiBfX3Nl
dHVwKCJwcm9tcHRfcmFtZGlzaz0iLCBwcm9tcHRfcmFtZGlzayk7DQogX19z
ZXR1cCgicmFtZGlzaz0iLCByYW1kaXNrX3NpemUpOw0KIF9fc2V0dXAoInJh
bWRpc2tfc2l6ZT0iLCByYW1kaXNrX3NpemUyKTsNCitfX3NldHVwKCJyYW1k
aXNrX2Jsb2Nrc2l6ZT0iLCByYW1kaXNrX2Jsb2Nrc2l6ZSk7DQogDQogI2Vu
ZGlmDQogDQpAQCAtMTg1LDYgKzE4MSw3IEBADQogew0KIAl1bnNpZ25lZCBp
bnQgbWlub3I7DQogCXVuc2lnbmVkIGxvbmcgb2Zmc2V0LCBsZW47DQorCXN0
cnVjdCBidWZmZXJfaGVhZCAqYnVmLCAqcmRfZGF0YTsNCiANCiByZXBlYXQ6
DQogCUlOSVRfUkVRVUVTVDsNCkBAIC0xOTYsNiArMTkzLDEyIEBADQogCQln
b3RvIHJlcGVhdDsNCiAJfQ0KIAkNCisJaWYgKChDVVJSRU5ULT5jbWQgIT0g
UkVBRCkgJiYgKENVUlJFTlQtPmNtZCAhPSBXUklURSkpIHsNCisJCXByaW50
ayhLRVJOX0lORk8gIlJBTURJU0s6IGJhZCBjb21tYW5kOiAlZFxuIiwgQ1VS
UkVOVC0+Y21kKTsNCisJCWVuZF9yZXF1ZXN0KDApOw0KKwkJZ290byByZXBl
YXQ7DQorCX0NCisNCiAJb2Zmc2V0ID0gQ1VSUkVOVC0+c2VjdG9yIDw8IDk7
DQogCWxlbiA9IENVUlJFTlQtPmN1cnJlbnRfbnJfc2VjdG9ycyA8PCA5Ow0K
IA0KQEAgLTIwNCwyNCArMjA3LDIwIEBADQogCQlnb3RvIHJlcGVhdDsNCiAJ
fQ0KIA0KLQlpZiAoKENVUlJFTlQtPmNtZCAhPSBSRUFEKSAmJiAoQ1VSUkVO
VC0+Y21kICE9IFdSSVRFKSkgew0KLQkJcHJpbnRrKEtFUk5fSU5GTyAiUkFN
RElTSzogYmFkIGNvbW1hbmQ6ICVkXG4iLCBDVVJSRU5ULT5jbWQpOw0KLQkJ
ZW5kX3JlcXVlc3QoMCk7DQotCQlnb3RvIHJlcGVhdDsNCisJYnVmID0gQ1VS
UkVOVC0+Ymg7DQorCWlmIChDVVJSRU5ULT5jbWQgPT0gUkVBRCkgew0KKwkJ
cmRfZGF0YSA9IGdldF9oYXNoX3RhYmxlKGJ1Zi0+Yl9kZXYsIGJ1Zi0+Yl9i
bG9ja25yLCBsZW4pOw0KKwkJaWYgKCFyZF9kYXRhKQ0KKwkJCW1lbXNldChD
VVJSRU5ULT5idWZmZXIsIDAsIGxlbik7DQorCQllbHNlIGlmIChyZF9kYXRh
ICE9IGJ1ZikNCisJCQltZW1jcHkoQ1VSUkVOVC0+YnVmZmVyLCByZF9kYXRh
LT5iX2RhdGEsIGxlbik7DQorCX0gZWxzZSB7DQorCQlyZF9kYXRhID0gZ2V0
YmxrKGJ1Zi0+Yl9kZXYsIGJ1Zi0+Yl9ibG9ja25yLCBsZW4pOw0KKwkJc2V0
X2JpdChCSF9Qcm90ZWN0ZWQsICZyZF9kYXRhLT5iX3N0YXRlKTsNCisJCWlm
IChyZF9kYXRhICE9IGJ1ZikNCisJCQltZW1jcHkocmRfZGF0YS0+Yl9kYXRh
LCBDVVJSRU5ULT5idWZmZXIsIGxlbik7DQogCX0NCi0NCi0JLyoNCi0JICog
SWYgd2UncmUgcmVhZGluZywgZmlsbCB0aGUgYnVmZmVyIHdpdGggMCdzLiAg
VGhpcyBpcyBva2F5IHNpbmNlDQotICAgICAgICAgKiB3ZSdyZSB1c2luZyBw
cm90ZWN0ZWQgYnVmZmVycyB3aGljaCBzaG91bGQgbmV2ZXIgZ2V0IGZyZWVk
Li4uDQotCSAqDQotCSAqIElmIHdlJ3JlIHdyaXRpbmcsIHdlIHByb3RlY3Qg
dGhlIGJ1ZmZlci4NCi0gIAkgKi8NCi0NCi0JaWYgKENVUlJFTlQtPmNtZCA9
PSBSRUFEKSANCi0JCW1lbXNldChDVVJSRU5ULT5idWZmZXIsIDAsIGxlbik7
IA0KLQllbHNlDQotCQlzZXRfYml0KEJIX1Byb3RlY3RlZCwgJkNVUlJFTlQt
PmJoLT5iX3N0YXRlKTsNCi0NCisJYnJlbHNlKHJkX2RhdGEpOw0KIAllbmRf
cmVxdWVzdCgxKTsNCiAJZ290byByZXBlYXQ7DQogfSANCg==
--432202577-1418353879-943851834=:5696--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/