[E-devel] NFS trouble (suggested patch included)
Dear E developers,
I recently found out that having one's config dir
on a NFS share is a bad idea. Enlightenment names its
background-thumbnail-files after inode, mtime and
_device_, which is a little pointless when the device
number is in the anonymous range (that is, majors
0, 144-146): Everytime your home gets mounted it
is (most probably) assigned a different device number,
causing the entire background cache to be rebuilt.
Even more, the old entries in the session config and
the thumbnails are not deleted, so you accumulate
a _LOT_ of redundant data over time.
Simply mapping all anonymous device numbers to a
single number in the same range fixes the problem -
patch is attached. It modifies code in:
- file.c:filedev()
- menus.c:MenuCreateFromDirectory()
and, as I stumbled across it, the EDBUG() entry
messages of
- file.c:fileinode() and filedev()
, which claimed to be the method filesize() (simple
copy&paste error).
Patch succeeds against latest CVS and latest available
tarball equally well. :)
I hope this is helpful!
Regards,
Jan Nordholz
PS: Please CC me in replies, I'm not subscribed.
--
Jan Nordholz
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
diff -Naur e16/src/file.c e16_new/src/file.c
--- e16/src/file.c Fri Aug 20 23:35:46 2004
+++ e16_new/src/file.c Mon Jan 24 13:05:44 2005
@@ -300,7 +300,7 @@
{
struct stat st;
- EDBUG(9, "filesize");
+ EDBUG(9, "fileinode");
if ((!s) || (!*s))
EDBUG_RETURN(0);
if (stat(s, &st) < 0)
@@ -313,11 +313,17 @@
{
struct stat st;
- EDBUG(9, "filesize");
+ EDBUG(9, "filedev");
if ((!s) || (!*s))
EDBUG_RETURN(0);
if (stat(s, &st) < 0)
EDBUG_RETURN(0);
+
+ /* device numbers in the anonymous range can't be relied
+ upon, so map them all on a single one */
+ if ((st.st_dev>>8)==0 || (st.st_dev>>8)==144 || \
+ (st.st_dev>>8)==145 || (st.st_dev>>8)==146)
+ EDBUG_RETURN(1);
EDBUG_RETURN((int)st.st_dev);
}
diff -Naur e16/src/menus.c e16_new/src/menus.c
--- e16/src/menus.c Fri Aug 20 23:35:46 2004
+++ e16_new/src/menus.c Mon Jan 24 12:47:23 2005
@@ -1091,6 +1091,7 @@
aa = (int)st.st_ino;
bb = (int)st.st_dev;
+if ((bb>>8)==0 || (bb>>8)==144 || (bb>>8)==145 || (bb>>8)==146)
bb=(int)1;
cc = 0;
if (st.st_mtime > st.st_ctime)
cc = st.st_mtime;
@@ -1215,6 +1216,7 @@
aa = (int)st.st_ino;
bb = (int)st.st_dev;
+ if ((bb>>8)==0 || (bb>>8)==144 || (bb>>8)==145 || (bb>>8)==146)
bb=(int)1;
cc = 0;
if (st.st_mtime > st.st_ctime)
cc = st.st_mtime;
Re: [E-devel] NFS trouble (suggested patch included)
On Monday, 24 January 2005, at 13:19:33 (+0100), Jan Nordholz wrote: > I recently found out that having one's config dir on a NFS share is > a bad idea. Enlightenment names its background-thumbnail-files after > inode, mtime and _device_, which is a little pointless when the > device number is in the anonymous range (that is, majors 0, > 144-146): E runs on more than just Linux. You cannot assume anything about device numbers. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "There's just something about debugging with a buggy debugger that reeks of rotten luck" --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] NFS trouble (suggested patch included)
Michael Jennings wrote: On Monday, 24 January 2005, at 13:19:33 (+0100), Jan Nordholz wrote: I recently found out that having one's config dir on a NFS share is a bad idea. Enlightenment names its background-thumbnail-files after inode, mtime and _device_, which is a little pointless when the device number is in the anonymous range (that is, majors 0, 144-146): E runs on more than just Linux. You cannot assume anything about device numbers. I have committed a fix doing essentially as suggested, but only if __linux__ is defined. /Kim --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] NFS trouble (suggested patch included)
On Tuesday, 01 February 2005, at 22:39:53 (+0100), Kim Woelders wrote: > I have committed a fix doing essentially as suggested, but only if > __linux__ is defined. Works for me. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "The future is all around us, waiting in moments of transition to be born in moments of revelation." -- G'Kar, Babylon 5 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] NFS trouble (suggested patch included)
On Sun, Jan 30, 2005 at 02:16:03AM -0500, Michael Jennings wrote: > On Monday, 24 January 2005, at 13:19:33 (+0100), > Jan Nordholz wrote: > > > I recently found out that having one's config dir on a NFS share is > > a bad idea. Enlightenment names its background-thumbnail-files after > > inode, mtime and _device_, which is a little pointless when the > > device number is in the anonymous range (that is, majors 0, > > 144-146): > > E runs on more than just Linux. You cannot assume anything about > device numbers. > > Michael Hi Michael. You're right, I forgot about the L in lanana.org. That makes the suggested patch useless, but the problem persists, which is not limited to a single OS. And as the assigned device number of a NFS mount is volatile by nature, and trying to determine the respective mount type at runtime (in order to decide whether E could trust the device number or not) would be too time-consuming for the job, wouldn't it be better to abandon the device number as identification altogether, replacing it by (for example) the lower 16 bits of the filesize? Perhaps not the best choice, as background images tend to be equally dimensioned, so a series of uncompressed images will all be equal in size... but I'd prefer too little cache-rebuilds over too many, especially as the old data isn't wiped out in that process. Just making suggestions and trying to be helpful (if you come to a decision involving some changes, I'd volunteer to write the appropriate patch)... Jan -- Jan Nordholz <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
