From linuxluck at 163.com Wed Dec 25 01:32:50 2013 From: linuxluck at 163.com (fsluck) Date: Wed, 25 Dec 2013 09:32:50 +0800 (CST) Subject: how to know ext cache hit rate? Message-ID: <1e217c12.2688.1432761fffb.Coremail.linuxluck@163.com> how to know ext cache hit rate? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Wed Dec 25 18:00:43 2013 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 25 Dec 2013 13:00:43 -0500 Subject: how to know ext cache hit rate? In-Reply-To: <1e217c12.2688.1432761fffb.Coremail.linuxluck@163.com> References: <1e217c12.2688.1432761fffb.Coremail.linuxluck@163.com> Message-ID: <20131225180043.GA10885@thunk.org> On Wed, Dec 25, 2013 at 09:32:50AM +0800, fsluck wrote: > how to know ext cache hit rate? Which cache are you referring to, specifically? The page cache? The inode cache? The dentry cache? What problem are you trying to solve, at a high level? - Ted From lakshmipathi.g at gmail.com Fri Dec 27 19:02:06 2013 From: lakshmipathi.g at gmail.com (Lakshmipathi.G) Date: Sat, 28 Dec 2013 00:32:06 +0530 Subject: expirer - a tool to delete files when they expire Message-ID: Hi - Though I'm not sure whether anyone will be interested in such tool (other than a possible SO user [1]). Here is a small tool to delete files at specific time in future. https://github.com/Lakshmipathi/expirer https://github.com/Lakshmipathi/expirer/blob/master/misc/ISSUES [1] http://programmers.stackexchange.com/questions/149824/automatically-delete-files-after-they-expire -- ---- Cheers, Lakshmipathi.G FOSS Programmer. www.giis.co.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at public.noschinski.de Mon Dec 16 08:18:29 2013 From: lars at public.noschinski.de (Lars Noschinski) Date: Mon, 16 Dec 2013 08:18:29 -0000 Subject: Recover files from a broken ext3 partition Message-ID: <52AEB74E.1050504@public.noschinski.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Please CC me on answers, I'm not subscribed] Hi everyone, I have got a hard disk which was damaged by a fall and would like to recover a few files from that. (There is a backup for most of the data, but a handful of recent files are missing. These are important enough to spend some time on them, but not for paying a professional data recovery service). Using GNU ddrescue I was able to read 99.8% of the partition, so there's hope the data is still there. Unfortunately, some key parts of the file system seem to be damaged, so e2fsck fails: - ------------------------------ % ddrescuelog -l- -b4096 sdd5.ddrescue.log > badblocks.sdd5.4096 % e2fsck -b 20480000 -v -f -L badblocks.sdd5.4096 sdd5 [...] Pass 1: Checking inodes, blocks, and sizes Block 1 in the primary group descriptors is on the bad block list If the block is really bad, the filesystem can not be fixed. You can remove this block from the bad block list and hope that the block is really OK. But there are no guarantees. - ------------------------------ [at 20480000 there seems to be an intact superblock; got the number (and the block size) from 'mke2fs -n'] The files I am interested in are located under /home/$USER/Desktop and /home/$USER/Dokumente; so I tried accessing them with debugfs. Unfortunately, /home/$USER seems to be corrupted: - ------------------------------ % LESS=FSRX debugfs -s 20480000 -b 4096 sdd5 debugfs 1.42.8 (20-Jun-2013) debugfs: cd /home/$USER debugfs: ls EXT2 directory corrupted - ------------------------------ So, any hints for me how to proceed? Is there a way to access the Desktop and Dokumente subdirectories (provided they are themselves undamaged)? Also, I interrupted ddrescue for my access attempt (because it takes really long to get all the still-good sectors from a 200GB partition). Can debugfs show me where on the disk /home/$USER is located? This would allow me to instruct ddrescue to concentrate on these parts. Best regards, Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJSrrdNAAoJEOUX5T7UhMS6jC0IAJfw81lWVe76yjXTxQirKRWz oDTmr7BTVHdXG9tw+v5aEuwItGkQVO4TjO/5A0weGa9Dl98VPERSw2AI2LK5OOIX gyJAXP566rZ/73J9fiPf4g8NucsA4yT49Pq8dISW1kwN9Y9fk5TM7v5Y5DCGUuc1 PfZK6rvqimB4YPLLXWtW69hKt/IEtGiRTtQ0GNSGUeamS+Qm02/sCcRfkU0KC4MK KblKfE49ApZU7zgH1GIoGmLI/cXWc/fmnbvsc/Pga+lapc7EAAtE691DSzZzu9zv sO5c/QCgiwSyEZFGwdHw306G5D+aI3MJSFUfbuj9dOTQ7MKnhhlalMv2UBMJpEM= =vIVl -----END PGP SIGNATURE-----