All of lore.kernel.org
 help / color / mirror / Atom feed
From: Massimo Cetra <ctrixk@navynet.it>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] disk full when it shouldn't
Date: Mon, 27 Dec 2010 15:31:03 +0100	[thread overview]
Message-ID: <4D18A327.7030709@navynet.it> (raw)
In-Reply-To: <4CF84658.8040002@oracle.com>


Il 03/12/2010 02:22, Tao Ma ha scritto:
> 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.
>

Hi Tao,

back again.

I have decided to install 2.6.36.1 on all clusters to see if the 
fragmentation problem has gone.

Unfortunately the problem persists, even if with different sympthoms.

Last week i had the same enospace problem but this time it was 
consistent on both nodes (on both of them i couldn't even "touch" a 
single file".
Previously i was able to touch it and sometimes to write several Mb to a 
single file.

This time df was reporting about 49% of disk usage.

I'm attaching the stat_sysdir output for both nodes. Kernel is a vanilla 
2.6.36.1.

Am i missing something ?
Is this fragmentation ?
Did i hit a bug or rhe problem is between the keyboard and the chair ?

Thanks for your help.

Massimo

P.S.: if you could explain how to interpret the stat_sysdir output i 
could be less tedius and write less mails!


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 23dic-OCFS-DRBD2-s2.txt
Url: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20101227/fc6941e2/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 23dic-OCFS-DRBD2-s1.txt
Url: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20101227/fc6941e2/attachment-0003.txt 

  parent reply	other threads:[~2010-12-27 14:31 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
2010-12-27 14:31       ` Massimo Cetra [this message]
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=4D18A327.7030709@navynet.it \
    --to=ctrixk@navynet.it \
    --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.