All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.