From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3075 invoked by alias); 20 Feb 2012 11:42:53 -0000 Received: (qmail 3066 invoked by uid 22791); 20 Feb 2012 11:42:52 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from www.meduna.org (HELO meduna.org) (92.240.244.38) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Feb 2012 11:42:37 +0000 Received: from [178.143.125.248] (helo=[192.168.130.22]) by meduna.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RzRdK-0006T6-PN for ecos-devel@ecos.sourceware.org; Mon, 20 Feb 2012 12:42:34 +0100 Message-ID: <4F423195.8070102@meduna.org> Date: Mon, 20 Feb 2012 11:42:00 -0000 From: Stanislav Meduna User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: jffs2 garbage collect thread Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: stano@meduna.org X-Authenticator: dovecot_plain X-Spam-Score: -6.9 X-Spam-Score-Int: -68 X-Exim-Version: 4.72 (build at 12-May-2011 18:13:45) X-Date: 2012-02-20 12:42:34 X-Connected-IP: 178.143.125.248:51621 X-Message-Linecount: 53 X-Body-Linecount: 42 X-Message-Size: 1637 X-Body-Size: 1227 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-02/txt/msg00006.txt.bz2 Hi, anyone knows whether it is now safe to enable the JFFS2 garbage collect thread? The CDL comment says: Enable background garbage collection thread, for making free space ahead of time. Leave this off till it's been implemented. And don't implement it till icache locking has been made thread-safe. The icache locking probably is not thread-safe per-se, but the fs-ecos.c says FSTAB_ENTRY(jffs2_fste, "jffs2", 0, CYG_SYNCMODE_FILE_FILESYSTEM | CYG_SYNCMODE_IO_FILESYSTEM, and the thread itself does cyg_fs_lock around the garbage collect pass cyg_fs_lock(mte, mte->fs->syncmode); if (jffs2_garbage_collect_pass(c) == -ENOSPC) { printf("No space for garbage collection. " "Aborting JFFS2 GC thread\n"); break; } cyg_fs_unlock(mte, mte->fs->syncmode); To me it looks safe - am I overlooking something? The reason I need to control garbage collect explicitely is that I need to make sure a filesystem has some amount of free space before starting an operation. So I want to trigger a garbage collect explicitely and then decide according to the superblock information. Can I use this model or are there any hidden dangers? Thanks -- Stano