headers
David Chinner | 2 Apr 2007 00:44
Picon
Favicon

Re: write barrier and USB devices

On Fri, Mar 30, 2007 at 03:23:57PM +0200, Martin Steigerwald wrote:
> 
> Hello!
> 
> Does the usb mass storage driver support write barriers?

You should ask the usb folks that question....

Cheers,

Dave.
--

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
Permalink | Reply | 0 comments |
headers
Timothy Shimmin | 2 Apr 2007 07:31
Picon
Favicon

review: remove unused ilen var from xfs_vnodeops.c

simple cleanup patch

===========================================================================
Index: fs/xfs/xfs_vnodeops.c
===========================================================================

--- a/fs/xfs/xfs_vnodeops.c	2007-04-02 15:56:30.000000000 +1000
+++ b/fs/xfs/xfs_vnodeops.c	2007-04-02 15:19:42.926081759 +1000
 <at>  <at>  -4289,7 +4289,6  <at>  <at>  xfs_free_file_space(
 	int			error;
 	xfs_fsblock_t		firstfsb;
 	xfs_bmap_free_t		free_list;
-	xfs_off_t		ilen;
 	xfs_bmbt_irec_t		imap;
 	xfs_off_t		ioffset;
 	xfs_extlen_t		mod=0;
 <at>  <at>  -4338,10 +4337,7  <at>  <at>  xfs_free_file_space(
 	}

 	rounding = max_t(uint, 1 << mp->m_sb.sb_blocklog, NBPP);
-	ilen = len + (offset & (rounding - 1));
 	ioffset = offset & ~(rounding - 1);
-	if (ilen & (rounding - 1))
-		ilen = (ilen + rounding) & ~(rounding - 1);

 	if (VN_CACHED(vp) != 0) {
 		xfs_inval_cached_trace(&ip->i_iocore, ioffset, -1,

=============================================================================
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Kujau | 2 Apr 2007 20:18
Picon

possible recursive locking detected

Hi,

when I enabled a few more debug-options in the kernel (vanilla 
2.6.21-rc5), I came across:

[ INFO: possible recursive locking detected ]
2.6.21-rc5 #2
---------------------------------------------
rm/32198 is trying to acquire lock:
xfs_ilock+0x71/0xa0

but task is already holding lock:
xfs_ilock+0x71/0xa0

other info that might help us debug this:
3 locks held by rm/32198:
do_unlinkat+0x96/0x160
vfs_unlink+0x75/0xe0
xfs_ilock+0x71/0xa0

stack backtrace:
__lock_acquire+0xa99/0x1010
lock_acquire+0x57/0x70
xfs_ilock+0x71/0xa0
down_write+0x38/0x50
xfs_ilock+0x71/0xa0
xfs_ilock+0x71/0xa0
xfs_lock_dir_and_entry+0xf6/0x100
xfs_remove+0x197/0x4e0
d_instantiate+0x19/0x40
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christoph Hellwig | 2 Apr 2007 22:02
Favicon

Re: review: remove unused ilen var from xfs_vnodeops.c

On Mon, Apr 02, 2007 at 04:31:52PM +1100, Timothy Shimmin wrote:
> simple cleanup patch

looks good.
Permalink | Reply | 0 comments |
headers
Charles Weber | 2 Apr 2007 23:18
Picon

Re: xfs partial dismount issue

Well actually I did a test with ext3 and got the same result. It partially
dismounted after a day or so of use and seemed identical to my previous xfs
filesystem failures . My guess now is that this has always occurred when all
6 raid controllers (2 per card)  were in use. I could go quite some time
with 5 of the 6 controllers used. I consolidated everything to 2 cards,
removed one card and put in fiber channel card for my new storage array So
far no problems. If so then it seems something is funny about the cciss
driver.

thanks,
Chuck

On 3/5/07, Roger Heflin <rheflin <at> atipa.com> wrote:
>
> Charles Weber wrote:
> > Eric Sandeen <sandeen <at> sandeen.net> writes:
> >
> >> Chuck Weber wrote:
> >>> Hi everyone, I have a long running problem perhaps you can help with.
> I
> >>> will include as much detail as I can. I can set up a spare server-disk
> >>> set for testing if you have any bright ideas.
> >>>
> >>> We use XFS for samba and nfs on x86_64 Fedora Proliant DL585/385
> >>> servers. Our busiest server has disk partitions go away.
> >> What do you mean by this, exactly?  The partitions themselves go away,
> >> or are you talking about the problem described below where processes
> >> start hanging?
> >>
> > Here is an example partition (1 of 6 or more xfs storage only).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Sandeen | 3 Apr 2007 01:45
Favicon
Gravatar

Re: review: remove unused ilen var from xfs_vnodeops.c

Timothy Shimmin wrote:
> simple cleanup patch
> 

Hey that's my job! ;-)

Looks good

-Eric
Permalink | Reply | 0 comments |
headers
Tim Shimmin | 3 Apr 2007 02:54
Picon
Favicon

TAKE cleanup - remove ilen refs from vnodeops.c

Remove unused ilen variable and references.

Date:  Tue Apr  3 10:53:20 AEST 2007
Workarea:  chook.melbourne.sgi.com:/build/tes/2.6.x-xfs
Inspected by:  lachlan <at> sgi.com,sandeen <at> sandeen.net

The following file(s) were checked into:
  longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb

Modid:  xfs-linux-melb:xfs-kern:28344a
fs/xfs/xfs_vnodeops.c - 1.694 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.694&r2=text&tr2=1.693&f=h
	- Remove unused ilen variable and references.
Permalink | Reply | 0 comments |
headers
ROBERT GLOBAL SUPPLIES INC | 3 Apr 2007 04:28

Request for Quote Price

             Request for Quote Price
Please quote us your firm price and available for the following items:
TO: Supplier

CDR,BRAND,700MB,80MIN,100SP ----- 20,000/pcs
USB FLASH DRIVES 1Gig or 2 Gig --------- 200/pcs
Centrino Core Duo Laptops Computer -------- 2/pcs ( Toshiba/HP /Sony).

Please indicate all prices FOB our place of business and indicate when your price quote shall expire. 
Please Advice payment Terms, Credit Card , Cashier Check or Wire Transfer is okay.

Sincerely
Robert Gonzalez

ROBERT GLOBAL SUPPLIES INC,
South 700 East,
South Salt Lake,
Salt Lake City, 84107
Tel: 801-938-5003
Fax: 866-384-6775
E-mail:sales_globalsuppliers <at> e2umail.com
Permalink | Reply | 0 comments |
headers
Timothy Shimmin | 3 Apr 2007 07:10
Picon
Favicon

review: export xfs_buftarg_list for use by xfsidbg

Hi,

This patch addresses the problem of having xfs_buftarg_list global for use
by kdb and xfsidbg, where otherwise it would be static.
If we are using xfsidbg, then we export the xfs_get_buftarg_list function
to it.
Previous to Dave's (dgc) static changes, we were only globalizing it if
we were in DEBUG - when really it is a question of xfsidbg.
Using CONFIG_KDB_MODULES as this is what we use in the Makefiles for
determining if xfsidbg is used.

--Tim

 linux-2.4/xfs_buf.c   |    8 ++++++++
 linux-2.4/xfs_buf.h   |    3 +++
 linux-2.4/xfs_ksyms.c |    5 ++---
 linux-2.6/xfs_buf.c   |   10 +++++++++-
 linux-2.6/xfs_buf.h   |    3 +++
 linux-2.6/xfs_ksyms.c |    5 ++---
 xfsidbg.c             |    9 +++------
 7 files changed, 30 insertions(+), 13 deletions(-)

===========================================================================
Index: fs/xfs/linux-2.4/xfs_buf.c
===========================================================================

--- a/fs/xfs/linux-2.4/xfs_buf.c	2007-04-03 15:47:15.000000000 +1000
+++ b/fs/xfs/linux-2.4/xfs_buf.c	2007-04-03 15:45:23.930213823 +1000
 <at>  <at>  -2335,3 +2335,11  <at>  <at>  xfs_buf_terminate(void)
 	kmem_zone_destroy(xfs_buf_zone);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sencer | 3 Apr 2007 13:03
Picon

md/dm devices, barrier support, commodity hardware and data integrity

Hello,

After reading up on XFS, there are a couple of issues that still seem
kind of cloudy to me. I am merely a user of filesystems, so forgive me
if some issues seem obvious. If you could confirm/clarify/answer the
following issues, it would be very helpful to me.

Situation 1)
We are currently using XFS on a commodity x86 server with SATA drives
(with NCQ) on Debian Etch (Kernel: 2.6.18-3-k7). We are also using
Software-Raid1 (mdadm). All partitions except /boot are XFS. If I
understand the FAQ and recent ml-discussions right, then

1a) without software-raid, we would enjoy write barrier support,
however given that we are using md-devices this is not the case
(kern.log confirms this by explicitly stating barrier support is
disabled for mdX ...). Did this (barrier support with XFS on md)
change in later kernels or is it likely to change in the near (or far)
future? (I think I read mentions of md, and some kind of
barrier-awareness on the ml, but didn't quite understand what
effectively  follows from it from a users POV).

1b) Given the current circumstances above, we should disable write
cache as suggested in the faq (there are actually UPS's but they've
failed before) to reduce the possibility of loosing data. Correct? We
did need to do some hard-resets, and had power failure, though as of
yet we never had problems with lost data on any xfs partitions, and
I'd like to make sure it stays that way.

1c) We have backup strategies in place, so I can live with having a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane