diff for duplicates of <20090609064855.GB5490@localhost> diff --git a/a/1.txt b/N1/1.txt index 6114341..77171bd 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -31,7 +31,7 @@ On Mon, Jun 08, 2009 at 10:46:53PM +0800, Nai Xia wrote: > >> > > >> > No. Note that pages are not locked in wait_on_page_writeback_range(). > >> -> >> I see. This function seems mostly called on the sync path, +> >> I see. This function seems mostly called A on the sync path, > >> it just waits for data being synchronized to disk. > >> No writers from the pages' POV, so no lock. > >> I missed this case, but my argument about the role of read/write lock. @@ -49,7 +49,7 @@ On Mon, Jun 08, 2009 at 10:46:53PM +0800, Nai Xia wrote: > >> > > >> >> that is the semantics of a writer waiting to get the lock while it's > >> >> acquired by -> >> >> some reader:The caller(e.g. truncate_inode_pages_range() and +> >> >> some reader:The caller(e.g. truncate_inode_pages_range() A and > >> >> invalidate_inode_pages2_range()) are the writers waiting for > >> >> writeback readers (as you clarified ) to finish their job, right ? > >> > @@ -77,14 +77,14 @@ On Mon, Jun 08, 2009 at 10:46:53PM +0800, Nai Xia wrote: > >> > >> 1. someone make index1-> page A > >> 2. Path P1 is acting as a *reader* to a cache page at index1 by -> >> setting PG_writeback on, while at the same time as a *writer* to -> >> the corresponding file blocks. -> >> 3. Another path P2 comes in and truncate page A, he is the writer -> >> to the same cache page. -> >> 4. Yet another path P3 comes as the writer to the cache page -> >> making it points to page B: index1--> page B. +> >> A A setting PG_writeback on, while at the same time as a *writer* to +> >> A A the corresponding file blocks. +> >> 3. Another path P2 comes in and A truncate page A, he is the writer +> >> A A to the same cache page. +> >> 4. Yet another path P3 comes A as the writer to the cache page +> >> A A A making it points to page B: index1--> page B. > >> 5. Path P4 comes writing back the cache page(and set PG_writeback). -> >> He is the reader of the cache page and the writer to the file blocks. +> >> A A He is the reader of the cache page and the writer to the file blocks. > >> > >> The corrupts occur because P1 & P4 races when writing file blocks. > >> But the _root_ of this racing is because nothing is used to serialize @@ -108,7 +108,7 @@ On Mon, Jun 08, 2009 at 10:46:53PM +0800, Nai Xia wrote: > > > > Please, that's a dangerous idea. A page can be written to at any time > > when writeback to disk is under way. Does PG_writeback (your reader -> > lock) prevents page data writers? NO. +> > lock) prevents page data writers? A NO. > > I meant PG_writeback stops writers to index---->struct page mapping. @@ -180,7 +180,7 @@ Fengguang > >> > Thanks, > >> > Fengguang > >> > -> >> >> > The writeback bit is _widely_ used. test_set_page_writeback() is +> >> >> > The writeback bit is _widely_ used. A test_set_page_writeback() is > >> >> > directly used by NFS/AFS etc. But its main user is in fact > >> >> > set_page_writeback(), which is called in 26 places. > >> >> > @@ -196,8 +196,8 @@ Fengguang > >> >> > > >> >> > The reason truncate_inode_pages_range() has to wait on writeback page > >> >> > is to ensure data integrity. Otherwise if there comes two events: -> >> >> > truncate page A at offset X -> >> >> > populate page B at offset X +> >> >> > A A A A truncate page A at offset X +> >> >> > A A A A populate page B at offset X > >> >> > If A and B are all writeback pages, then B can hit disk first and then > >> >> > be overwritten by A. Which corrupts the data at offset X from user's POV. > >> >> > @@ -213,8 +213,14 @@ Fengguang > >> >> > -- > >> >> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >> >> > the body of a message to majordomo@vger.kernel.org -> >> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html -> >> >> > Please read the FAQ at http://www.tux.org/lkml/ +> >> >> > More majordomo info at A http://vger.kernel.org/majordomo-info.html +> >> >> > Please read the FAQ at A http://www.tux.org/lkml/ > >> >> > > >> > > > + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 9b24c15..4591a68 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -55,7 +55,7 @@ "> >> >\n" "> >> > No. Note that pages are not locked in wait_on_page_writeback_range().\n" "> >>\n" - "> >> I see. This function seems mostly called \302\240on the sync path,\n" + "> >> I see. This function seems mostly called A on the sync path,\n" "> >> it just waits for data being synchronized to disk.\n" "> >> No writers from the pages' POV, so no lock.\n" "> >> I missed this case, but my argument about the role of read/write lock.\n" @@ -73,7 +73,7 @@ "> >> >\n" "> >> >> that is the semantics of a writer waiting to get the lock while it's\n" "> >> >> acquired by\n" - "> >> >> some reader:The caller(e.g. truncate_inode_pages_range() \302\240and\n" + "> >> >> some reader:The caller(e.g. truncate_inode_pages_range() A and\n" "> >> >> invalidate_inode_pages2_range()) are the writers waiting for\n" "> >> >> writeback readers (as you clarified ) to finish their job, right ?\n" "> >> >\n" @@ -101,14 +101,14 @@ "> >>\n" "> >> 1. someone make index1-> page A\n" "> >> 2. Path P1 is acting as a *reader* to a cache page at index1 by\n" - "> >> \302\240 \302\240 setting PG_writeback on, while at the same time as a *writer* to\n" - "> >> \302\240 \302\240 the corresponding file blocks.\n" - "> >> 3. Another path P2 comes in and \302\240truncate page A, he is the writer\n" - "> >> \302\240 \302\240 to the same cache page.\n" - "> >> 4. Yet another path P3 comes \302\240as the writer to the cache page\n" - "> >> \302\240 \302\240 \302\240making it points to page B: index1--> page B.\n" + "> >> A A setting PG_writeback on, while at the same time as a *writer* to\n" + "> >> A A the corresponding file blocks.\n" + "> >> 3. Another path P2 comes in and A truncate page A, he is the writer\n" + "> >> A A to the same cache page.\n" + "> >> 4. Yet another path P3 comes A as the writer to the cache page\n" + "> >> A A A making it points to page B: index1--> page B.\n" "> >> 5. Path P4 comes writing back the cache page(and set PG_writeback).\n" - "> >> \302\240 \302\240He is the reader of the cache page and the writer to the file blocks.\n" + "> >> A A He is the reader of the cache page and the writer to the file blocks.\n" "> >>\n" "> >> The corrupts occur because P1 & P4 races when writing file blocks.\n" "> >> But the _root_ of this racing is because nothing is used to serialize\n" @@ -132,7 +132,7 @@ "> >\n" "> > Please, that's a dangerous idea. A page can be written to at any time\n" "> > when writeback to disk is under way. Does PG_writeback (your reader\n" - "> > lock) prevents page data writers? \302\240NO.\n" + "> > lock) prevents page data writers? A NO.\n" "> \n" "> I meant PG_writeback stops writers to index---->struct page mapping.\n" "\n" @@ -204,7 +204,7 @@ "> >> > Thanks,\n" "> >> > Fengguang\n" "> >> >\n" - "> >> >> > The writeback bit is _widely_ used. \302\240test_set_page_writeback() is\n" + "> >> >> > The writeback bit is _widely_ used. A test_set_page_writeback() is\n" "> >> >> > directly used by NFS/AFS etc. But its main user is in fact\n" "> >> >> > set_page_writeback(), which is called in 26 places.\n" "> >> >> >\n" @@ -220,8 +220,8 @@ "> >> >> >\n" "> >> >> > The reason truncate_inode_pages_range() has to wait on writeback page\n" "> >> >> > is to ensure data integrity. Otherwise if there comes two events:\n" - "> >> >> > \302\240 \302\240 \302\240 \302\240truncate page A at offset X\n" - "> >> >> > \302\240 \302\240 \302\240 \302\240populate page B at offset X\n" + "> >> >> > A A A A truncate page A at offset X\n" + "> >> >> > A A A A populate page B at offset X\n" "> >> >> > If A and B are all writeback pages, then B can hit disk first and then\n" "> >> >> > be overwritten by A. Which corrupts the data at offset X from user's POV.\n" "> >> >> >\n" @@ -237,10 +237,16 @@ "> >> >> > --\n" "> >> >> > To unsubscribe from this list: send the line \"unsubscribe linux-kernel\" in\n" "> >> >> > the body of a message to majordomo@vger.kernel.org\n" - "> >> >> > More majordomo info at \302\240http://vger.kernel.org/majordomo-info.html\n" - "> >> >> > Please read the FAQ at \302\240http://www.tux.org/lkml/\n" + "> >> >> > More majordomo info at A http://vger.kernel.org/majordomo-info.html\n" + "> >> >> > Please read the FAQ at A http://www.tux.org/lkml/\n" "> >> >> >\n" "> >> >\n" - > > + "> >\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -407f5423c6dcd58351d4886b4f1af2cc72e401247ee44fe83b5c315a2c7b2015 +c228633e49d5b4ee0f3d62804102724596090b3d36537bf29ab658dcb7a581c6
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.