diff for duplicates of <af8b0006-0eb7-468a-bbf8-36ecec9bec35@default> diff --git a/a/1.txt b/N1/1.txt index fffcb6b..d04c4c4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,11 +2,11 @@ > Sent: Tuesday, August 03, 2010 12:34 PM > To: Dan Magenheimer > Subject: Re: [PATCH V3 0/8] Cleancache: overview ->=20 +> > On 2010-08-03, at 11:35, Dan Magenheimer wrote: > > - The FS should be block-device-based (e.g. a ram-based FS > > such as tmpfs should not enable cleancache) ->=20 +> > When you say "block device based", does this exclude network > filesystems? It would seem cleancache, like fscache, is actually best > suited to high-latency network filesystems. @@ -17,10 +17,10 @@ leaves out the possibility of network FSs, I am just displaying my general ignorance of FSs and I/O, and welcome clarification from FS developers. What I really meant is: Don't use cleancache for RAM-based filesystems. -=20 + > > - To ensure coherency/correctness, inode numbers must be unique > > (e.g. no emulating 64-bit inode space on 32-bit inode numbers) ->=20 +> > Does it need to be restricted to inode numbers at all (i.e. can it use > an opaque internal identifier like the NFS file handle)? Disallowing > cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32- diff --git a/a/content_digest b/N1/content_digest index a8b4123..508384f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -39,11 +39,11 @@ "> Sent: Tuesday, August 03, 2010 12:34 PM\n" "> To: Dan Magenheimer\n" "> Subject: Re: [PATCH V3 0/8] Cleancache: overview\n" - ">=20\n" + "> \n" "> On 2010-08-03, at 11:35, Dan Magenheimer wrote:\n" "> > - The FS should be block-device-based (e.g. a ram-based FS\n" "> > such as tmpfs should not enable cleancache)\n" - ">=20\n" + "> \n" "> When you say \"block device based\", does this exclude network\n" "> filesystems? It would seem cleancache, like fscache, is actually best\n" "> suited to high-latency network filesystems.\n" @@ -54,10 +54,10 @@ "displaying my general ignorance of FSs and I/O, and\n" "welcome clarification from FS developers. What I really\n" "meant is: Don't use cleancache for RAM-based filesystems.\n" - "=20\n" + " \n" "> > - To ensure coherency/correctness, inode numbers must be unique\n" "> > (e.g. no emulating 64-bit inode space on 32-bit inode numbers)\n" - ">=20\n" + "> \n" "> Does it need to be restricted to inode numbers at all (i.e. can it use\n" "> an opaque internal identifier like the NFS file handle)? Disallowing\n" "> cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32-\n" @@ -85,4 +85,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -516e8d133b9b20f66814314cff2fe545d601c786097b771c3ae61230ea93296a +6c5383bcba6d12e7c4117dc5d9744a7fad5368e2ce493faf4c80e4351ef2387a
diff --git a/a/1.txt b/N2/1.txt index fffcb6b..6d5ecf4 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -2,11 +2,11 @@ > Sent: Tuesday, August 03, 2010 12:34 PM > To: Dan Magenheimer > Subject: Re: [PATCH V3 0/8] Cleancache: overview ->=20 +> > On 2010-08-03, at 11:35, Dan Magenheimer wrote: > > - The FS should be block-device-based (e.g. a ram-based FS > > such as tmpfs should not enable cleancache) ->=20 +> > When you say "block device based", does this exclude network > filesystems? It would seem cleancache, like fscache, is actually best > suited to high-latency network filesystems. @@ -17,10 +17,10 @@ leaves out the possibility of network FSs, I am just displaying my general ignorance of FSs and I/O, and welcome clarification from FS developers. What I really meant is: Don't use cleancache for RAM-based filesystems. -=20 + > > - To ensure coherency/correctness, inode numbers must be unique > > (e.g. no emulating 64-bit inode space on 32-bit inode numbers) ->=20 +> > Does it need to be restricted to inode numbers at all (i.e. can it use > an opaque internal identifier like the NFS file handle)? Disallowing > cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32- @@ -41,9 +41,3 @@ every call that may always be zero on most FSs. Thanks, Dan - --- -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/N2/content_digest index a8b4123..d20d525 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -5,7 +5,7 @@ "ref\0a7f4db53-c348-4cff-8762-7ea4031e4813@default 22A6238E-0BA4-4AB9-A4FA-28B206A47513@oracle.com\0" "ref\022A6238E-0BA4-4AB9-A4FA-28B206A47513@oracle.com\0" "From\0Dan Magenheimer <dan.magenheimer@oracle.com>\0" - "Subject\0RE: [PATCH V3 0/8] Cleancache: overview\0" + "Subject\0[Ocfs2-devel] [PATCH V3 0/8] Cleancache: overview\0" "Date\0Tue, 3 Aug 2010 12:09:54 -0700 (PDT)\0" "To\0Andreas Dilger <andreas.dilger@oracle.com>\0" "Cc\0Boaz Harrosh <bharrosh@panasas.com>" @@ -39,11 +39,11 @@ "> Sent: Tuesday, August 03, 2010 12:34 PM\n" "> To: Dan Magenheimer\n" "> Subject: Re: [PATCH V3 0/8] Cleancache: overview\n" - ">=20\n" + "> \n" "> On 2010-08-03, at 11:35, Dan Magenheimer wrote:\n" "> > - The FS should be block-device-based (e.g. a ram-based FS\n" "> > such as tmpfs should not enable cleancache)\n" - ">=20\n" + "> \n" "> When you say \"block device based\", does this exclude network\n" "> filesystems? It would seem cleancache, like fscache, is actually best\n" "> suited to high-latency network filesystems.\n" @@ -54,10 +54,10 @@ "displaying my general ignorance of FSs and I/O, and\n" "welcome clarification from FS developers. What I really\n" "meant is: Don't use cleancache for RAM-based filesystems.\n" - "=20\n" + " \n" "> > - To ensure coherency/correctness, inode numbers must be unique\n" "> > (e.g. no emulating 64-bit inode space on 32-bit inode numbers)\n" - ">=20\n" + "> \n" "> Does it need to be restricted to inode numbers at all (i.e. can it use\n" "> an opaque internal identifier like the NFS file handle)? Disallowing\n" "> cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32-\n" @@ -77,12 +77,6 @@ "every call that may always be zero on most FSs.\n" "\n" "Thanks,\n" - "Dan\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>" + Dan -516e8d133b9b20f66814314cff2fe545d601c786097b771c3ae61230ea93296a +6698cade80cff08ae3916f72893c4c79563a30b3f9aec30836425bdd9a7916c9
diff --git a/a/1.txt b/N3/1.txt index fffcb6b..6d5ecf4 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -2,11 +2,11 @@ > Sent: Tuesday, August 03, 2010 12:34 PM > To: Dan Magenheimer > Subject: Re: [PATCH V3 0/8] Cleancache: overview ->=20 +> > On 2010-08-03, at 11:35, Dan Magenheimer wrote: > > - The FS should be block-device-based (e.g. a ram-based FS > > such as tmpfs should not enable cleancache) ->=20 +> > When you say "block device based", does this exclude network > filesystems? It would seem cleancache, like fscache, is actually best > suited to high-latency network filesystems. @@ -17,10 +17,10 @@ leaves out the possibility of network FSs, I am just displaying my general ignorance of FSs and I/O, and welcome clarification from FS developers. What I really meant is: Don't use cleancache for RAM-based filesystems. -=20 + > > - To ensure coherency/correctness, inode numbers must be unique > > (e.g. no emulating 64-bit inode space on 32-bit inode numbers) ->=20 +> > Does it need to be restricted to inode numbers at all (i.e. can it use > an opaque internal identifier like the NFS file handle)? Disallowing > cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32- @@ -41,9 +41,3 @@ every call that may always be zero on most FSs. Thanks, Dan - --- -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/N3/content_digest index a8b4123..9481793 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -39,11 +39,11 @@ "> Sent: Tuesday, August 03, 2010 12:34 PM\n" "> To: Dan Magenheimer\n" "> Subject: Re: [PATCH V3 0/8] Cleancache: overview\n" - ">=20\n" + "> \n" "> On 2010-08-03, at 11:35, Dan Magenheimer wrote:\n" "> > - The FS should be block-device-based (e.g. a ram-based FS\n" "> > such as tmpfs should not enable cleancache)\n" - ">=20\n" + "> \n" "> When you say \"block device based\", does this exclude network\n" "> filesystems? It would seem cleancache, like fscache, is actually best\n" "> suited to high-latency network filesystems.\n" @@ -54,10 +54,10 @@ "displaying my general ignorance of FSs and I/O, and\n" "welcome clarification from FS developers. What I really\n" "meant is: Don't use cleancache for RAM-based filesystems.\n" - "=20\n" + " \n" "> > - To ensure coherency/correctness, inode numbers must be unique\n" "> > (e.g. no emulating 64-bit inode space on 32-bit inode numbers)\n" - ">=20\n" + "> \n" "> Does it need to be restricted to inode numbers at all (i.e. can it use\n" "> an opaque internal identifier like the NFS file handle)? Disallowing\n" "> cleancache on a filesystem that uses 64-bit (or larger) inodes on a 32-\n" @@ -77,12 +77,6 @@ "every call that may always be zero on most FSs.\n" "\n" "Thanks,\n" - "Dan\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>" + Dan -516e8d133b9b20f66814314cff2fe545d601c786097b771c3ae61230ea93296a +652617ffed2e5fb73f3219770fe3644e4deb58c7af764863b2347e3a65e71813
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.