From: Tao Ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] disk full when it shouldn't
Date: Fri, 03 Dec 2010 10:16:16 +0800 [thread overview]
Message-ID: <4CF852F0.6060702@oracle.com> (raw)
In-Reply-To: <4CF84658.8040002@oracle.com>
Hi Massimo,
I just noticed anther thing.
The inode_alloc:0000 isn't full, so node1 should steal inode from node0,
why it can't? You delete some files in node0?
Regards,
Tao
On 12/03/2010 09:22 AM, Tao Ma wrote:
> Hi Massimo,
> Massimo Cetra wrote:
>> Il 09/11/2010 02:06, Tao Ma ha scritto:
>>> Hi Massimo,
>>>
>>> From the output, it seems that you shouldn't meet with ENOSPC problem
>>> at that time. So when you meet with ENOSPC, could you please do 'sync'
>>> first(that will sync the metadata to the disk so that stat_sysdir can
>>> output the real metadata info) and then do stat_sysdir?
>>>
>>> btw, you can also try to 'touch' one new file in your ocfs2 volume. So
>>> if it succeeds, it means that the inode_alloc is ok. Otherwise, your
>>> inode_alloc has no space. Please also try this test when you meet with
>>> ENOSPC.
>>
>> Hi Tao,
>>
>> As i supposed, the problem arose another time.
>>
>> Attached you may find the stat_sysdir output.
> Got it.
>>
>>
>> For the sake of completeness, have to say that:
>>
>> - The output of df was the following:
>>
>> # df -i
>> Filesystem Inode IUsati ILib. IUso% Montato su
>> [CUT]
>> /dev/drbd2 9174751 4695156 4479595 52% /var/mail
>>
>> # df
>> Filesystem blocchi di 1K Usati Disponib. Uso% Montato su
>> [CUT]
>> /dev/drbd2 36699004 18780656 17918348 52% /var/mail
> I have to say that df is only an approximate way to get the real info of
> an ocfs2 volume.
> df -i use statfs(2). And since there is no easy way to calculate all the
> inodes without
> locking every node's inode allocator, it just searchs the global_bitmap
> and gives a rough number.
>
>>
>> The filesystem was not full:
>>
>> sheet3-1:/var/mail/virtual# dd if=/dev/zero of=TEST bs=1024 count=1024
>> dd: scrittura di `TEST': No space left on device
>> 1009+0 records in
>> 1008+0 records out
>> 1032192 bytes (1,0 MB) copied, 0,454305 s, 2,3 MB/s
>> sheet3-1:/var/mail/virtual#
> So this is node2? From the stat_sysdir output you attached,
> inode_alloc:0001 is full.
> It has no free inodes and the creation will fail.
>
> So you are meeting with the problem of fragmentation. Discontig block
> group should fix it.
>
> Regards,
> Tao
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel
next prev parent reply other threads:[~2010-12-03 2:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 15:14 [Ocfs2-devel] disk full when it shouldn't Massimo Cetra
2010-11-09 1:06 ` Tao Ma
2010-12-02 17:20 ` Massimo Cetra
2010-12-03 1:22 ` Tao Ma
2010-12-03 2:16 ` Tao Ma [this message]
2010-12-27 14:31 ` Massimo Cetra
2010-12-27 15:48 ` Tao Ma
2010-12-27 16:52 ` Sunil Mushran
2010-12-28 11:38 ` Massimo Cetra
2010-12-28 12:06 ` Massimo Cetra
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=4CF852F0.6060702@oracle.com \
--to=tao.ma@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/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.