From: Chris AtLee <catlee@canada.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Linux MTD <linux-mtd@lists.infradead.org>
Subject: Re: Problems unlinking files
Date: 02 Jul 2002 12:37:38 -0400 [thread overview]
Message-ID: <1025627858.919.28.camel@geb> (raw)
In-Reply-To: <26464.1024529622@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1427 bytes --]
Sorry for the delay, I was on vacation last week. Attached is a log of
what I get with CONFIG_JFFS2_FS_DEBUG=1 and /proc/sys/kernel/printk = 9
In addition, I notice that if I keep unlinking the file, the link count
goes from 0 to 65535 then 65534, 65533, ...
I've put up a tarball with my 2.2.18 changes at:
http://atlee.ca/jffs2-2.2.18.tar.gz
Cheers,
Chris
On Wed, 2002-06-19 at 19:33, David Woodhouse wrote:
>
> catlee@canada.com said:
> > I've noticed some problems with unlinking files with JFFS2 in my linux
> > 2.2.18 port. After unlinking a file, it doesn't appear in the
> > directory listing, but if I do an 'ls' on the unlinked file, I can
> > still get information on the file. I can still read and write to the
> > file, but it refuses to show up in the directory listing. After I
> > unmount the JFFS2 partition and remount it the file isn't there at
> > all.
>
> Can you run with CONFIG_JFFS2_FS_DEBUG=1 and show the output while you
> unlink the file, then open it again?
>
> Preferably using a serial console, and they'll be KERN_DEBUG messages so
> you'll need to echo 9 > /proc/sys/kernel/printk to make them get printed.
>
> > Any ideas? I'm sure I must have deleted something important getting
> > everything working with linux 2.2.18.
>
> Show me your jffs2_unlink() and jffs2_do_unlink() -- and indeed the rest of
> it :)
>
> --
> dwmw2
>
>
>
[-- Attachment #1.2: minicom.cap --]
[-- Type: text/plain, Size: 2722 bytes --]
# touch test2
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_lookup()
jffs2_create()
jffs2_new_inode(): dir_i 1, mode 0x81a4
Allocated inocache at c05181d0
jffs2_do_new_inode(): Assigned ino# 29
jffs2_reserve_space(): Requested 0x44 bytes
jffs2_reserve_space(): alloc sem got
jffs2_do_reserve_space(): Giving 0xf3a0 bytes at 0x1d0c60
jffs2_do_create(): reserved 0xf3a0 bytes
jffs2_add_physical_node_ref(): Node at 0x1d0c60, size 0x44
jffs2_write_dnode wrote node at 0x001d0c60 with dsize 0x0, csize 0x0, node_crc 0xe0303e57, data_crc 0x00000000, totlen 0x00000044
jffs2_do_create created file with mode 0x81a4
jffs2_write_dirent(ino #1, name at *0xc04fa304 "test2"->ino #29, name_crc 0xd5997a45)
jffs2_add_physical_node_ref(): Node at 0x1d0ca4, size 0x30
jffs2_add_fd_to_list( c01f4e60, c0535b4c (->c01f4f20))
jffs2_complete_reservation()
thread_should_wake(): nr_free_blocks 41, nr_erasing_blocks 0, dirty_size 0x1fcfc (mod 0x1fcfc
): no
jffs2_create: Created ino #29 with mode 100644, nlink 1(1)
# ls -l test2
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
-rw-r--r-- 1 root root 0 Jan 1 00:04 test2
# rm test2
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_reserve_space(): Requested 0x30 bytes
jffs2_reserve_space(): alloc sem got
jffs2_do_reserve_space(): Giving 0xf32c bytes at 0x1d0cd4
jffs2_write_dirent(ino #1, name at *0xc04fa304 "test2"->ino #0, name_crc 0xd5997a45)
jffs2_add_physical_node_ref(): Node at 0x1d0cd4, size 0x30
jffs2_add_fd_to_list( c01f4920, c0535b4c (->c01f4f20))
Marking old dirent node (ino #29) obsolete
obliterating obsoleted node at 0x001d0ca4
jffs2_complete_reservation()
thread_should_wake(): nr_free_blocks 41, nr_erasing_blocks 0, dirty_size 0x1fd2c (mod 0x1fd2c
): no
# ls -l test2
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
jffs2_readdir() for dir_i #1
Dirent 0: ".", ino #1
Dirent 1: "..", ino #1
jffs2_readdir() for dir_i #1
-rw-r--r-- 0 root root 0 Jan 1 00:04 test2
#
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2002-07-02 16:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-19 15:13 Problems unlinking files Chris AtLee
2002-06-19 23:33 ` David Woodhouse
2002-07-02 16:37 ` Chris AtLee [this message]
2002-09-11 13:42 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1025627858.919.28.camel@geb \
--to=catlee@canada.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.