* What is the logic behind 'Device or resource busy' ?
@ 2003-05-26 23:59 Jure Pecar
2003-05-27 0:39 ` Joe Pruett
0 siblings, 1 reply; 8+ messages in thread
From: Jure Pecar @ 2003-05-26 23:59 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
Hi all,
Consider the situation where a drive sdx gets kicked out of a mirror md9. If
i want to add it back with mdadm /dev/md9 -a /dev/sdx1, i get the 'device
busy' error.
However, if i stop the mirror and start it right after, i can easily add the
sdx1 back into md9. But this also requires me to stop any services using
this mirror and unmount the filesystem on it...
Any particular reason that this must work that way?
--
Jure Pecar
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: What is the logic behind 'Device or resource busy' ?
2003-05-26 23:59 What is the logic behind 'Device or resource busy' ? Jure Pecar
@ 2003-05-27 0:39 ` Joe Pruett
2003-05-27 2:41 ` How do we handle the same but uptodated data to disk cache? bmoon
2003-05-27 2:56 ` What is the logic behind 'Device or resource busy' ? Jure Pecar
0 siblings, 2 replies; 8+ messages in thread
From: Joe Pruett @ 2003-05-27 0:39 UTC (permalink / raw)
To: Jure Pecar; +Cc: linux-raid
i don't know the mdadm equivalent, but i do raidhotremove followed by
raidhotadd to get around that issue. if you look at /proc/mdstat after
the failure, you'll probably see the drive is still part of the array, but
just marked as down. raidhotremove tells the system it is gone and then
you can add it back.
^ permalink raw reply [flat|nested] 8+ messages in thread
* How do we handle the same but uptodated data to disk cache?
2003-05-27 0:39 ` Joe Pruett
@ 2003-05-27 2:41 ` bmoon
2003-05-27 2:47 ` Neil Brown
2003-05-27 2:56 ` What is the logic behind 'Device or resource busy' ? Jure Pecar
1 sibling, 1 reply; 8+ messages in thread
From: bmoon @ 2003-05-27 2:41 UTC (permalink / raw)
To: linux-raid
Hello,
I want to write the data to the fixed sector with the same size frequently
just like MD super block, but I do not want to sync and flush the dev
on each write.
For example, to write md super block in /drivers/md/md.c
we do
fsync_dev(dev);
bh=getblk(dev, block, size);
mark_buffer_uptodate(bh,1);
mark_buffer_dirty(bh);
ll_rw_block(WRITE,1, &bh);
wait_on_buffer(bh);
brelse(bh);
fsync_dev(dev);
Instead, Can I do as follow
bh=getblk(dev, block, size);
if (buffer_uptodate(bh)) { /* still in cache, not flushed yet */
bh->b_data = new SB data;
brelse(bh);
}
else { /* it must be flushed */
same as in above
}
Please provide me your openion or suggestions.
Thanks in advance,
Bo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How do we handle the same but uptodated data to disk cache?
2003-05-27 2:41 ` How do we handle the same but uptodated data to disk cache? bmoon
@ 2003-05-27 2:47 ` Neil Brown
2003-05-27 20:47 ` bmoon
0 siblings, 1 reply; 8+ messages in thread
From: Neil Brown @ 2003-05-27 2:47 UTC (permalink / raw)
To: bmoon; +Cc: linux-raid
On Monday May 26, bo@anthologysolutions.com wrote:
> Hello,
>
> I want to write the data to the fixed sector with the same size frequently
> just like MD super block, but I do not want to sync and flush the dev
> on each write.
>
> For example, to write md super block in /drivers/md/md.c
I suggest you look at a newer md.c. With 2.4.21pre or 2.5.* have
"sync_page_io" which does what you want more effectively.
NeilBrown
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: What is the logic behind 'Device or resource busy' ?
2003-05-27 0:39 ` Joe Pruett
2003-05-27 2:41 ` How do we handle the same but uptodated data to disk cache? bmoon
@ 2003-05-27 2:56 ` Jure Pecar
1 sibling, 0 replies; 8+ messages in thread
From: Jure Pecar @ 2003-05-27 2:56 UTC (permalink / raw)
To: Joe Pruett; +Cc: linux-raid
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
On Mon, 26 May 2003 17:39:45 -0700 (PDT)
Joe Pruett <joey@q7.com> wrote:
> i don't know the mdadm equivalent, but i do raidhotremove followed by
> raidhotadd to get around that issue. if you look at /proc/mdstat after
> the failure, you'll probably see the drive is still part of the array, but
>
> just marked as down. raidhotremove tells the system it is gone and then
> you can add it back.
hm yes... a failed drive is still present and has to be removed. makes sense
now, thanks.
--
Jure Pecar
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How do we handle the same but uptodated data to disk cache?
2003-05-27 2:47 ` Neil Brown
@ 2003-05-27 20:47 ` bmoon
2003-05-28 20:29 ` bmoon
2003-05-30 4:07 ` Neil Brown
0 siblings, 2 replies; 8+ messages in thread
From: bmoon @ 2003-05-27 20:47 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
Neil,
It improved a lot for the sync I/O.
However, I am looking for a solution to handle
the regular async I/O with a page data on the
same sector repeatedly like writing the MD SB
data to disk without flushing.
The follwing is my simple algorithm for it;
bh=getblk(dev, block, size);
if (buffer_uptodate(bh)) { /* still in cache, not flushed yet */
bh->b_data = "updated data";
brelse(bh);
}
else { /* all were flushed or new */
.
.
mark_buffer_uptodate(bh,1);
mark_buffer_dirty(bh);
generic_make_request(rw, &bh);
}
Please give me your suggestion or comment.
Bo
----- Original Message -----
From: "Neil Brown" <neilb@cse.unsw.edu.au>
To: "bmoon" <bo@anthologysolutions.com>
Cc: <linux-raid@vger.kernel.org>
Sent: Monday, May 26, 2003 7:47 PM
Subject: Re: How do we handle the same but uptodated data to disk cache?
> On Monday May 26, bo@anthologysolutions.com wrote:
> > Hello,
> >
> > I want to write the data to the fixed sector with the same size
frequently
> > just like MD super block, but I do not want to sync and flush the dev
> > on each write.
> >
> > For example, to write md super block in /drivers/md/md.c
>
> I suggest you look at a newer md.c. With 2.4.21pre or 2.5.* have
> "sync_page_io" which does what you want more effectively.
>
> NeilBrown
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How do we handle the same but uptodated data to disk cache?
2003-05-27 20:47 ` bmoon
@ 2003-05-28 20:29 ` bmoon
2003-05-30 4:07 ` Neil Brown
1 sibling, 0 replies; 8+ messages in thread
From: bmoon @ 2003-05-28 20:29 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
Help!
There must be a function which will update the data in the disk cache.
From __make_request(), it does ordering(neighboring) the requests,
it does not deal with the same block request.
Please give me a light!
>
> It improved a lot for the sync I/O.
> However, I am looking for a solution to handle
> the regular async I/O with a page data on the
> same sector repeatedly like writing the MD SB
> data to disk without flushing.
>
> The follwing is my simple algorithm for it;
>
> bh=getblk(dev, block, size);
> if (buffer_uptodate(bh)) { /* still in cache, not flushed yet */
> bh->b_data = "updated data";
> brelse(bh);
> }
> else { /* all were flushed or new */
> .
> .
> mark_buffer_uptodate(bh,1);
> mark_buffer_dirty(bh);
> generic_make_request(rw, &bh);
> }
>
> Please give me your suggestion or comment.
>
Bo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: How do we handle the same but uptodated data to disk cache?
2003-05-27 20:47 ` bmoon
2003-05-28 20:29 ` bmoon
@ 2003-05-30 4:07 ` Neil Brown
1 sibling, 0 replies; 8+ messages in thread
From: Neil Brown @ 2003-05-30 4:07 UTC (permalink / raw)
To: bmoon; +Cc: linux-raid
On Tuesday May 27, bo@anthologysolutions.com wrote:
> Neil,
>
> It improved a lot for the sync I/O.
> However, I am looking for a solution to handle
> the regular async I/O with a page data on the
> same sector repeatedly like writing the MD SB
> data to disk without flushing.
This is a filesystem question. Not a raid question.
I would just:
getblk
copy new data in
mark update
mark dirty
release block
and it will eventually be flushed to disk.
If you want to written sooner, call
submit_bh
NeilBrown
>
> The follwing is my simple algorithm for it;
>
> bh=getblk(dev, block, size);
> if (buffer_uptodate(bh)) { /* still in cache, not flushed yet */
> bh->b_data = "updated data";
> brelse(bh);
> }
> else { /* all were flushed or new */
> .
> .
> mark_buffer_uptodate(bh,1);
> mark_buffer_dirty(bh);
> generic_make_request(rw, &bh);
> }
>
> Please give me your suggestion or comment.
>
>
> Bo
> ----- Original Message -----
> From: "Neil Brown" <neilb@cse.unsw.edu.au>
> To: "bmoon" <bo@anthologysolutions.com>
> Cc: <linux-raid@vger.kernel.org>
> Sent: Monday, May 26, 2003 7:47 PM
> Subject: Re: How do we handle the same but uptodated data to disk cache?
>
>
> > On Monday May 26, bo@anthologysolutions.com wrote:
> > > Hello,
> > >
> > > I want to write the data to the fixed sector with the same size
> frequently
> > > just like MD super block, but I do not want to sync and flush the dev
> > > on each write.
> > >
> > > For example, to write md super block in /drivers/md/md.c
> >
> > I suggest you look at a newer md.c. With 2.4.21pre or 2.5.* have
> > "sync_page_io" which does what you want more effectively.
> >
> > NeilBrown
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-30 4:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-26 23:59 What is the logic behind 'Device or resource busy' ? Jure Pecar
2003-05-27 0:39 ` Joe Pruett
2003-05-27 2:41 ` How do we handle the same but uptodated data to disk cache? bmoon
2003-05-27 2:47 ` Neil Brown
2003-05-27 20:47 ` bmoon
2003-05-28 20:29 ` bmoon
2003-05-30 4:07 ` Neil Brown
2003-05-27 2:56 ` What is the logic behind 'Device or resource busy' ? Jure Pecar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox