headers
Vlad Apostolov | 1 Nov 2006 01:44
Picon
Favicon

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

John Groves wrote:
> I'm running up against a difficult situation because dm_path_to_handle 
> does not return a handle, if the path is to a directory.  Is this a 
> known issue, or perhaps fixed in a recent version?  Or is there 
> another way get the handle of a directory by path?  When any file type 
> is renamed, I (for various reasons) *must* know not just the old & new 
> parent handles, but also the handle of the renamed thingy.  If the 
> thingy is a directory, I'm stuck at the moment.
>
> My test system has dmapi 2.2.1-5, which I don't think is current, but 
> I can't seem to get access to the oss.sgi.com server to check.
>
> Any advice or info appreciated.  I'm willing to try and submit a 
> patch, but I'd appreciate first knowing whether there was a specific 
> reason or problem that led to the current behavior.
>
> Thanks,
> John Groves
>
Hi John,

If your path is longer than 2000 characters dm_path_to_handle used to fail.
This bug was fixed in August 2006. Please update your tree from here:

http://oss.sgi.com/projects/xfs/download.html

Regards,
Vlad
(Continue reading)

Permalink | Reply | 7 comments |
headers
Vlad Apostolov | 1 Nov 2006 01:57
Picon
Favicon

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

Vlad Apostolov wrote:
> John Groves wrote:
>> I'm running up against a difficult situation because 
>> dm_path_to_handle does not return a handle, if the path is to a 
>> directory.  Is this a known issue, or perhaps fixed in a recent 
>> version?  Or is there another way get the handle of a directory by 
>> path?  When any file type is renamed, I (for various reasons) *must* 
>> know not just the old & new parent handles, but also the handle of 
>> the renamed thingy.  If the thingy is a directory, I'm stuck at the 
>> moment.
>>
>> My test system has dmapi 2.2.1-5, which I don't think is current, but 
>> I can't seem to get access to the oss.sgi.com server to check.
>>
>> Any advice or info appreciated.  I'm willing to try and submit a 
>> patch, but I'd appreciate first knowing whether there was a specific 
>> reason or problem that led to the current behavior.
>>
>> Thanks,
>> John Groves
>>
> Hi John,
>
> If your path is longer than 2000 characters dm_path_to_handle used to 
> fail.
> This bug was fixed in August 2006. Please update your tree from here:
>
> http://oss.sgi.com/projects/xfs/download.html
>
> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Per Mellander | 1 Nov 2006 23:36
Picon

xfs_growfs after lvextend don't increase mounted size.

Hi!

I've got a 6.5TB xfs filesystem on a LVM2 volume. I wanted to increase 
the size of the fs so I added another ~10TB to the volume. Every step 
taken was successfull, (ie no errors) but the filesystem size remained 
unchanged even after the xfs_growfs.

What I did was the following:

I extended the lvm using pvcreate, vgextend and finally lvextend. pvscan 
gives:

   PV /dev/sda1   VG vg01   lvm2 [1.59 TB / 0    free]
   PV /dev/sdb1   VG vg01   lvm2 [1.59 TB / 0    free]
   PV /dev/sdc1   VG vg01   lvm2 [1.59 TB / 0    free]
   PV /dev/sdd1   VG vg01   lvm2 [1.59 TB / 0    free]
   PV /dev/sde1   VG vg01   lvm2 [2.00 TB / 0    free]
   PV /dev/sdf1   VG vg01   lvm2 [2.00 TB / 0    free]
   PV /dev/sdg1   VG vg01   lvm2 [2.00 TB / 0    free]
   PV /dev/sdh1   VG vg01   lvm2 [2.00 TB / 0    free]
   PV /dev/sdi1   VG vg01   lvm2 [1.55 TB / 0    free]
   Total: 9 [15.91 TB] / in use: 9 [15.91 TB] / in no VG: 0 [0   ]

and lvdisplay:

   --- Logical volume ---
   LV Name                /dev/vg01/lv01
   VG Name                vg01
   LV UUID                rDSEQ3-DdhV-oLci-nNYT-dMdX-cppA-7v1r3e
   LV Write Access        read/write
(Continue reading)

Permalink | Reply | 2 comments |
headers
Shailendra Tripathi | 2 Nov 2006 00:59

Re: xfs_growfs after lvextend don't increase mounted size.

Hi,

Do you have this patch in your kernel  (reference pasted below)?

Because, you are trying to grow with blocks which overflows a data 
field. This is pretty silent change and you don't notice it.

(gdb) p/x  10*1024*1024*1024/4
$3 = 0xe0000000

-shailendra
I am pasting the conversation for your reference

On Wed, Oct 11, 2006 at 03:25:57PM +1000, David Chinner wrote:
> On Mon, Sep 25, 2006 at 02:08:11PM +0530, Shailendra Tripathi wrote:
> > Hi David,
> >           As part of fixing xfs_reserve_blocks issue, you might want to 
> > fix an issue in xfs_trans_unreserve_and_mod_sb as well. Since, I am on 
> > much older version, my patch is not applicable on newer trees. However, 
> > the patch is attached for your reference.
> > 
> > The problem is as below:
> > 
> > Superblock modifications required during transaction are stored in delta 
> > fields in transaction. These fields are applied to the superblock when 
> > transaction commits.

.....

> So, looking a little deeper:
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Chinner | 2 Nov 2006 04:42
Picon
Favicon

Re: xfs_growfs after lvextend don't increase mounted size.

On Wed, Nov 01, 2006 at 11:36:59PM +0100, Per Mellander wrote:
> Hi!
> 
> I've got a 6.5TB xfs filesystem on a LVM2 volume. I wanted to increase 
> the size of the fs so I added another ~10TB to the volume. Every step 
> taken was successfull, (ie no errors) but the filesystem size remained 
> unchanged even after the xfs_growfs.

There's a 32 bit overflow in the growfs code (and transaction code
on 32 bit systems) so you can't grow by more than 2TB at a time.
I've got a fix under test for this at the moment.

Can you see if you can grow using:

# xfs_growfs -D <current size + (2TB / FSB) - 1> </path/to/mntpt>

FSB = filesystem block size, and the current size is also in FSB.
You can get both the current size and the FSB from xfs_growfs -n <mtpt>

Cheers,

Dave.
--

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
Permalink | Reply | 0 comments |
headers
John Novak | 2 Nov 2006 04:56

xfs over iscsi via initiator on CentOS 4.4

Does anyone have information about running an xfs file system over iscsi 
from the CentOS 4.4 iscsi initiator ?

The only post I could find about this is one from Aug of 04 indicating a 
known issue.  (http://oss.sgi.com/archives/xfs/2004-08/msg00155.html)

I tries this on CentOS 4.4 with kernel 2.6.9-42.0.3.plus.c4smp running 
on a dual core AMD proc.  I'm seeing the same symptom as reported in 
this earlier post.

Any pointers are appreciated,

Best,

John Novak
Permalink | Reply | 0 comments |
headers
Tracy | 2 Nov 2006 12:44
Picon

question about your photo


   I've accidently found [1]your photo at a flickr and i'm very interested in
   it.
   Can you tell me what place i can see in the background of it?
   ---
   wbr, Donald

References

   1. file://localhost/home/cmf3/tasks/keepeer_au_1/vz7wdv/http://www.previewhomepro.com/flickr.html

[[HTML alternate version deleted]]
Permalink | Reply | 0 comments |
headers
Christian Guggenberger | 2 Nov 2006 18:26
Picon
Favicon

mount failed after xfs_growfs beyond 16 TB

Hi,

a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on
top of lvm2 to 17TB. (I am not even sure if that's supposed work with
linux-2.6, 32bit)

used kernel seems to be debian sarge's 2.6.8

xfs_growfs seemed to succeed (AFAIK..)

however, the fs shut down:

XFS internal error
XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c.  Caller
0xf89978a8
[__crc_pm_idle+550816/2056674] xfs_free_ag_extent+0x454/0x78a [xfs]
[__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs]
[__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs]
[__crc_pm_idle+553757/2056674] xfs_alloc_read_agf+0xbe/0x1e4 [xfs]
[__crc_pm_idle+764480/2056674] xfs_growfs_data_private+0xd80/0xec0 [xfs]
[pty_write+305/307] pty_write+0x131/0x133
[opost+154/428] opost+0x9a/0x1ac
[__crc_pm_idle+765024/2056674] xfs_growfs_data+0x3f/0x5e [xfs]
[__crc_pm_idle+972873/2056674] xfs_ioctl+0x256/0x860 [xfs]
[tty_write+436/788] tty_write+0x1b4/0x314
[write_chan+0/538] write_chan+0x0/0x21a
[__crc_pm_idle+968754/2056674] linvfs_ioctl+0x78/0x101 [xfs]
[sys_ioctl+315/675] sys_ioctl+0x13b/0x2a3
[syscall_call+7/11] syscall_call+0x7/0xb
xfs_force_shutdown(dm-1,0x8) called
(Continue reading)

Permalink | Reply | 11 comments |
headers
Eric Sandeen | 2 Nov 2006 19:38
Favicon
Gravatar

Re: mount failed after xfs_growfs beyond 16 TB

Christian Guggenberger wrote:
> Hi,
> 
> a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on
> top of lvm2 to 17TB. (I am not even sure if that's supposed work with
> linux-2.6, 32bit)

If you have CONFIG_LBD enabled (do you?), it should in theory, barring
bugs :)

> used kernel seems to be debian sarge's 2.6.8

hmm old....

> xfs_growfs seemed to succeed (AFAIK..)

trace below looks like not...

> however, the fs shut down:
> 
> XFS internal error
> XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c.  Caller
> 0xf89978a8
> [__crc_pm_idle+550816/2056674] xfs_free_ag_extent+0x454/0x78a [xfs]
> [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs]
> [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs]
> [__crc_pm_idle+553757/2056674] xfs_alloc_read_agf+0xbe/0x1e4 [xfs]

in the growfs thread here
(Continue reading)

Permalink | Reply | 6 comments |
headers
Uri Rotshtein | 2 Nov 2006 20:18
Picon

Adding xfs to kernel 2.4.20

Hi,

I'm using kernel 2.4.20 with Redhat 9 and would like to try the XFS
filesystem. 

10x, Uri.

[[HTML alternate version deleted]]
Permalink | Reply | 1 comment |

Gmane