lkml.org 
[lkml]   [1998]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject[RFC] [PATCH] Dirty pages in the page cache
From
Date

What follows is a patch to allow dirty pages in the page cache.

It uses the `writepage' function of an inode, to write out dirty pages
from the page cache. I have a filesystem that currently uses this and
shows performace comparable with ext2.

The basic idea of use is a filesystem will set an extra dirty on a
page, when a write occurs to it. And if the dirty bit is set it is
garanteed that before the page is removed from memory `writepage' will
be called. For filesystems that need more precise tracking they
should be able to do that on their own.

The only place my patch sets the dirty bit is in file truncation, for
the partially truncated page. But this is unnecarry. Oops.

This patch is 99% complete. With the pushing of the dentry code all
of the way down to the `readpage' & `writepage' functions in 2.1.78,
my design has broken down.

With cached writes logically it is a function of the inode to handle
the writes. This allows you to continue caching even after a single
link name has been deleted, or renamed. But it seems to be convinient
to have a dentry when you are actually writing.

The question is how to get that dentry, and how to keep it up to date.
There are two possibilities I see.
1) Keep a known path in the inode by which we can get a default
dentry.
2) Keep a dentry field in struct page (possibly replacing the inode
field), to use when writing the page. And is updated when we
notice the page is dirty by a writer.

Option 2 seems like a logical extension. However with delayed writes
the dentry may be stale by the time we actually get to writing. And
with multiple writers whose dentry is the correct one, to use?

Option 1 is the one I prefer, as it leaves all of the which dentry is
the correct one to use in a centralized location, and doesn't increase
the size of struct page.

Which ever method is used, generic_file_write can be modified
to do the correct thing if `writepage' is implemented, so it is no
challenge at all for filesystem designers. It can also be left to
updatepage.

There is still the question of partial writes, and how to track them
for filesystems that deem that important.

And as a complimentary question should sys_sync be modified to sync
the page cache as well? And which other sync functions should sync
the page cache.

My preliminary but tested patch:

begin 644 linux-2.1.78.x4.diff.gz
M'XL("&MSN30"`VQI;G5X+3(N,2XW."YX-"YD:69F`*48:U/;1O"S_"LVTQDJ
M6W[)YF%#H$D+S=`!DH%D^OBBD:63K4$/5SI!:$-_>_?V3K)D2\:TF8G%W3[N
M]KU[KN]YT,MNDM\@\*/L:\^?1W'">IX?L%1MC?IF_VC2_SH>>.G`CV*7]9TU
MT'X)U.KU>ELHM5^9"[_8$<`1#,?'P\/CT13,Z732,@QC"UOMSN9$9PYAA'0'
MQZ8IZ=Z]@]ZD>PC&I'L$[]ZUX#L_<H+,9?"6V`U2GOC1O+\XVP2%8>VVZ]C.
M@@F0L0Y:VG,6VDLB:\&@TP+HP`U[A%PS?K@,6,@B;G,_COITO9$Y[4[`&(V&
M77-,=X3.H`4/L>^"$S`[L8A:QYMF#I>LH$.?=@O^;O4TWP.=UKTSWXH2<8NT
MW3+J]Y'"T+1!!\0'KW?I`5\PQ79AI^#Z"7\"0H;'Q.=,P$.(XL>^)!F(3_H4
M.=:25*'N)V]TT@)-PYM&CLT5Q")>$MZ%(:(8VC.B/=H^M^)H@UQ<^_+.^O7V
M\O/['Z\N%`3V]J`0)IVM+7MG[I]6O&R+TS>W\9/$R^((]U6.K6P\6#G%AB=N
MHM0Z^B9:V7'-Z?'^P?%PO]GAM],+Q]]'%BO'-\?D^N*CG-]EGA\Q^/3!.K]^
MKZ$QCRJ;=X$]$[N3RF[Z:"\MLC2"INCU*Y"PK`19Y#::.:R0)BQER0-S-6UL
MRI"`:_L>O8W#,F&<^RP!'@-G*2<OM&?Q`^OW^\+)2((#DR0X&*U+@`>C"+JX
M0%O3=,'!FOE<EZ)U84^">F=>8,_3=KM**@2MI16`%XE1'S\)F16'"H.5LFK8
M&&4VQ.)<:*V.S[IF7[K4K=)T':_<"G4\UD1CO*0:/64O*>;_A%*1+5]P]`)O
MAZ`J<"DR[M@2X!#,T?'!\'A$)>%HA\BJ,MD27N/NO@BOL7+.%K"OG"61S-W9
MTA4I\"&49ES+WUW(HA25A04OB*-Y%YPXPB!P%G8B@'[$12YL&66.Y9SKL@?]
M'G\L#O@K<FH39EWU@#P5&FA_%J$57VG)>SR*!8/[]"E,:RI^%5QKMRJ*=AU'
M<,X<P(*/91]SH3EM-M<:[58KC8;[(H6(CRJO%[]]^GC[V;K[_?K'CU=ZNL`&
MX-Z251W#+F%2]54LC!!75;,H"V<LD=;!?":<!8@8/*QZHJZG5".K#$KQG/I_
MD>IK$+#^+BQNSX(:A#7K;T<H[%M%L:R\Z%(<2_MCO7TC<X"K__3QYN?+#];-
MSW?G5'%K]JWKC^=?KB[:ZRIR8ROR4I%I'!X(]2C'$D883PZ%$<;3,;8ZFS:P
M+#=^C#:U;EG9<G,W94Z6L(`]L&!3PI"TT""^!$KER6ID!P',LC3T'49=5Q7?
M=ETKC+.468D=N7$8L31]=?\0A@,!$`EE,U#*P-HP*2.\KEMHHMP,D<,#81S\
ME6FLU$&IIK'7H[9.-&9Z9PFGY/2]LPA33AO>G,+-EZLK:KTT!&-UP-K^4&")
MA6CY--G,-M<WB2XK"YVW.@7D&:5==42QF[`06P?)UDOB4(;2GQG+5)D^(5&G
M1T+4Z:00M4G6783=*NWKQ6V0MT'@724V39PK3"Q3YJB+1E<&1N%BS\/Z#F_A
MT_L/%];=Y1\78C80G"N5"3`(L(%(E8266N9'"/R0A<A)UZGT=-H%:R.G;6/;
MWUV=`SV0&&VIJ5*;L9.>O"!#20F5QQB:H9Z?0W`Q6^#_9Y&@4S%IX=P5!:+%
MH0LJO9'*5L?E!9+2>8>$:QEB5'J=&8U=S%*#)$O+&I:%,":QBLUG3-EK4F&O
M`+<,,]G36EO9)%)=+U`X,*WD'7F&_41=JUH,7Y4I+%Z*)5)">:]W1D.DH&N^
M?DFO0M^R//W/^PN^+$GB!$'#$S4.U^J)6*O!6/%VL0M(GL#-PA"-W)'+$U"C
M\Y<41Q4)S#&SB/L!;LYPJL&AQD_!B[/([:MQ687(GF*(T2"Z@-C3::,M`X'^
M[JL^`V]=B**I0TY!,J"]7+9Z7>N2I`N%-SV#TL$;HE3ROM:]GU>>(?DHHY(9
M52\58LW1R:R)'^.%GJB?!3>TZ<$"-.4`U3SC!+%S+VU%>>L0&[:A:-R*=Q&9
M=%'_J%V<(.UR[R7^_(%*N*:2=\D=VO1,HNV6-!L0:R)48M9$:<Z"U&3*)*>1
M0^(>BKC:VL4E%:\\`6^$26%A\>\96(#>62*LS795&O55%\:/S+,BBV[H?)9Y
M'CKXFM9EISV1%ML_ZAX,5:51/!T,!IX_[KQ9YG;9Q.AM-U&[%J-B&T*I,4G9
M',UZSY7>H&H522L=-^E7*I>$R@U>"ATEK$R'+\UVE:0GDR&H=+JV&_BA+]C2
M[?%8S#H6QJ+8(=!J"VOS]?M/ULVMOO#G"PMWX^2)[NS%B7XB&6*S(SG2TC"J
M*;+\$+F9?4G%0KE7&-7YLT3NT#CK<NQ6)>)SCEU4E*:2H^.8\@#?OJU2GEB?
MGI*6<MXOQ<BSM`1IGEY!0;U)V9B2HWD@G!J[';Y(XFR^H%<IZ@O[$O7S`@/A
MT<>Q86[C4,`9HQDB+K^BRK=3G"3I_382#R]$ZY>1_#3ZG@./,[PI(N!\0<`B
M@0.>ST5]3#/'8<Q-^X+'H,9=MCP/-WO.RDD*9=*U-UV`.DY0R.5>^.__9N9M
MF6XWXU%K)Y[7*>OL3[&9-\:CHJ>OR-L1V4.5'9O'..BAOAQ=U36*0\H.I3H'
M>Z?PCZZ;\/:M>,/,ECP6+SEM^`;%IBRA[3S67DU9WEFONFUJ8R5;U4F?JH99
B`,10FO>^Y<2GWM>+OMRRRIAK=:X+I)>3UK\M+@GBY1D``&UJ
`
end

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.053 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site