Chris Mason wrote:
Daniel Phillips wrote:
Simply stated, the new cache design divides filesystem blocks into two
classes: those that can be memory-mapped and those that can't. There
is no defined way to move a given block from one class to the other.
This is the sequence of events
Alexander Viro wrote:
Do it in -prepare_write() if page is the last one. End of story. You'll
have to call the thing in your truncate() (expanding case) and that's it.
Pageout _never_ changes the file size, write and truncate own the -i_sem.
So "page covers the end of file" is not going to
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
This is getblk, except for pages. It finds or sets up a page in a
mapping. It puts buffers on the page if necessary but doesn't cause
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
There is a very heavy investment in generic_read/write/mmap - I don't
want to throw that away. This is a mod to Ext2, and Ext2 uses these
Oh, but these functions don't need to be modified. Change
Alexander Viro wrote:
On Wed, 13 Sep 2000, Daniel Phillips wrote:
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
There is a very heavy investment in generic_read/write/mmap - I don't
want to throw that away. This is a mod to Ext2, and Ext2 uses
I'm going to admit that I've always been confused about the deep
meaning of some of the buffer state bits. There are four buffer state
bits that describe the relationship between the cached in a buffer and
data stored on disk:
BH_Uptodate
BH_Dirty
BH_Mapped
BH_New
Does anybody think
After staring at the block device code for, um, quite a long time, I
came to the conclusion that blk_size stores one less than the number of
512 byte blocks on a device. Is this true?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message
Daniel Phillips wrote:
After staring at the block device code for, um, quite a long time, I
came to the conclusion that blk_size stores one less than the number of
512 byte blocks on a device. Is this true?
Um, slight revision: they wouldn't be blocks, they'd be 'sectors
Curtis Anderson wrote:
So it's not clear how you reached to the conclusion that directories
shouldn't be pressed into service as compound files. I'm sure you have
a reason, but it wasn't revealed here!
It's an aesthetics argument. There are no new features in a directory-based
Curtis Anderson wrote:
It all depends on how optional things are, and what differences an unmodified
app sees. IMHO, "none" is the right answer in this case. Part of my believing
that directory-hack stream-style attributes are not good is that I don't know
how to do them without making
"Stephen C. Tweedie" wrote:
On Mon, Oct 30, 2000 at 09:34:27AM -0500, Chris Mason wrote:
Yes, reiserfs could do it the same way, if we start putting a transaction
handle pointer in the task struct.
But, I thought you required some way of knowing when the transaction was
broken up
Martin Frey wrote:
What I don't understand is what happens if somebody
writes to a mmaped area. The page will certainly be
modifed. Reads will see the modification since the
page is in page cache. What about a write that
modifies a part of the same page? The contents in
the page cache is
There was talk of exposing some kind of transaction API now that we have
a crop of fs's on the way that can do transactions. Has this gone
anywhere?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
"Stephen C. Tweedie" wrote:
On Sun, Oct 29, 2000 at 02:45:32PM +0100, Andreas Gruenbacher wrote:
If so, then the client's kernel could map these id's to the proper names
when needed, right?
Yes. Exactly. You're getting the point --- it is possible for a
client to manage the mapping
"Stephen C. Tweedie" wrote:
I have to admit that when I first looked at your proposal I thought it
was overkill, but having followed the thread all the way through I now
have some appreciation of the weird wacky world out there that you are
dealing with. I think your approach is correct. Here
[EMAIL PROTECTED] wrote:
Hi all. I have a need to stretch a file (rapidly) to a new
allocated size, but do not want to actually write data by
the current machine at the current time (I just need there to
be allocated blocks).
Take a look at the function i wrote below. This works. But
i
After quite a lot of grepping in 2.4.0-test10 I was unable to find any
places where address_mapping-host is not (struct inode *) - are there
any?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Christoph Hellwig wrote:
On Tue, Nov 14, 2000 at 12:04:21PM +0100, Daniel Phillips wrote:
After quite a lot of grepping in 2.4.0-test10 I was unable to find any
places where address_mapping-host is not (struct inode *) - are there
any?
I can't find one. This change was requested some
Alexander Viro wrote:
On Tue, 14 Nov 2000, Daniel Phillips wrote:
After quite a lot of grepping in 2.4.0-test10 I was unable to find any
places where address_mapping-host is not (struct inode *) - are there
any?
Currently - none. As soon as block devices go to pagecache we'll have
Daniel Phillips wrote:
Even if I can find the filesystem that belongs to a given page, how does
the filesystem find a (struct file *) for the page so it can do
address_space-writepage?
Never mind, I know what to do here - don't use the address_space
function, write my own. Not as clean
Steve Lord wrote:
Currently - none. As soon as block devices go to pagecache we'll have such
beasts (you need one address_space for all inodes with given major:minor,
so -host can't point to any of them). Possibly earlier, if somebody will
need address_space in some other
Alexander Viro wrote:
On Wed, 15 Nov 2000, Rik van Riel wrote:
On Tue, 14 Nov 2000, Alexander Viro wrote:
On Tue, 14 Nov 2000, Daniel Phillips wrote:
After quite a lot of grepping in 2.4.0-test10 I was unable to find any
places where address_mapping-host is not (struct inode
Daniel Phillips wrote:
...At this
point we need to be to get the page's inode efficiently - it's sitting
there in the -host field, no problem, except now you're talking about
putting other things there with no way to know what they are. Do you
have another suggestion on how to find
Alexander Viro wrote:
Anyway, yes, fs-wide metadata is an obvious user for that stuff. E.g.
for FFS-like beasts inode table just begs for such treatment. Waiting
for 2.5... Patch treats cylinder group descriptors as analogs of indirect
blocks - that allows to play with alternative allocation
David Gibson wrote:
I've discovered that my ramfs limits patch has been broken for some
time due to a slight change in the handling of PG_dirty (specifically
it is cleared in truncate_complete_page() before the call to
remove_inode_page().
In tracking this down I became rather confused
Rik van Riel wrote:
On Mon, 20 Nov 2000, Andrea Arcangeli wrote:
On Mon, Nov 20, 2000 at 05:42:48PM +1100, David Gibson wrote:
[..] What am I missing?
You should rename it to PG_protected.
Why?
PG_dirty is a perfectly adequate name. If we have a method
to clean the page, it
Andreas Gruenbacher wrote:
Hmmm. I don't see any use of notify_change with any of ATTR_FLAG_APPEND,
ATTR_FLAG_SYNCHRONOUS, ATTR_FLAG_NOATIME, ATTR_FLAG_IMMUTABLE set, so that
part of notify_change is not invoked. Currently, these special inode flags
are set through ioctl() directly.
Is the
Alexander Viro wrote:
On Thu, 23 Nov 2000, Daniel Phillips wrote:
Not strictly related to ext2, but having sys_truncate call vmtruncate
via notify_change seems like a bizarre arrangement that could be cleaned
up. There are filesystems that rely on this behaviour (once again NFS
Linda Walsh wrote:
In that context do you know of any code that solves this
problem I could nab or is Plan 10 the most expedient (doing
the ENV var substitution).
Clearly some earthlings need enlightenment regarding the origin of the
name Plan 9:
Alexander Viro wrote:
In all fairness, -read_inode() should not be a method. Correct way to
deal with that would be along the lines
[...]
+ if (inode-i_state I_NEW) {
+ ext2_read_inode(inode);
+ unlock_new_inode(inode);
+
On Thu, 08 Mar 2001, Matthew Wilcox wrote:
On Thu, Mar 08, 2001 at 11:16:10AM -0500, Alexander Viro wrote:
I'm not sure on your #2. In principle, -i_fop can be NULL. It may be
a good thing to declare that it should never happens, but right now it's
not guaranteed.
Besides, revoke-like
-- Forwarded Message --
Subject: Re: RFC: [PATCH] ext2 BLOCK_SIZE independence
Date: Mon, 12 Mar 2001 13:45:32 +0100
From: Daniel Phillips [EMAIL PROTECTED]
On Mon, 12 Mar 2001, Anton Altaparmakov wrote:
At 02:44 12/03/2001, Alexander Viro wrote:
On Mon, 12 Mar 2001, Anton
On Tue, 13 Mar 2001, Alexander Viro wrote:
On Mon, 12 Mar 2001, Daniel Phillips wrote:
I'm not at all comfortable with the way we are handling i_size right
now - it gets set in a funny way:
- vmtruncate sets i_size lower
- _commit_write sets it higher
Coding for this feels
On Thu, 15 Mar 2001, Trond Myklebust wrote:
" " == Daniel Phillips [EMAIL PROTECTED] writes:
Only file_write, truncate and high level filesystem code code
should set i_size.
That's only true for local filesystems. Networked filesystems can
decide to set i_size a
On Tuesday 24 April 2001 15:24, Dirk Mueller wrote:
(I posted this already but got no response. Am I really posting to the
wrong list ??)
Hi,
I have a small problem when using the directory notifications. when the
directory itself that I watch in my program is deleted, I don't receive an
On Thursday 03 May 2001 03:15, you wrote:
Hello Daniel,
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Later,
Albert
Thanks Albert, this was easily
On Thursday 17 May 2001 17:53, Andrew Morton wrote:
It's probably worth thinking about adding a fourth journalling
mode: `journal=none'. Roll it all up into a single codebase
and call it ext4.
Or ext5 (= ext2 + ext3).
It rather depends on where the buffercache ends up. ext3 is
a client
On Friday 18 May 2001 11:10, Alexander Viro wrote:
On Thu, 17 May 2001, Daniel Phillips wrote:
Well, if you look how I did the index, it works with blocks and
buffers while still staying entirely in the page cache. This was
Stephen's suggestion, and it integrates reliably with Al's
page
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for registering an array of related devices
(almost always two: raw and ctl) and their legacy
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for registering an array of related devices (almost
always two: raw and ctl) and their legacy device numbers with a
single userspace callout that does whatever /dev/ creation needs to
be done. Thus,
On Friday 25 May 2001 00:00, Hans Reiser wrote:
Daniel Phillips wrote:
I suppose I'm just reiterating the obvious, but we should
eventually have a generic filesystem transaction API at the VFS
level, once we have enough data points to know what the One True
API should be.
Daniel
On Thursday 24 May 2001 22:59, Edgar Toernig wrote:
Daniel Phillips wrote:
Readdir fills in a directory type, so ls sees it as a directory
and does the right thing. On the other hand, we know we're on
a device filesystem so we will next open the name as a regular
file, and find
On Monday 21 May 2001 14:43, [EMAIL PROTECTED] wrote:
How about:
# mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
# ls /dev/mypartition
basesizedevicetype
Generally, we shouldn't care which order the kernel enumerates
devices in or which
On Thursday 24 May 2001 23:26, Alexander Viro wrote:
On Thu, 24 May 2001, Edgar Toernig wrote:
What *won't* happen is, you won't get side effects from opening
your serial ports (you'd have to open them without O_DIRECTORY
to get that) so that seems like a little step forward.
As
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
Daniel Phillips wrote:
It won't, the open for . is handled in the VFS, not the
filesystem - it will open the directory. (Without needing to be
told it's a directory via O_DIRECTORY.) If you do open(magicdev)
you'll get the device
On Monday 21 May 2001 10:14, Lars Marowsky-Bree wrote:
On 2001-05-19T16:25:47,
Daniel Phillips [EMAIL PROTECTED] said:
How about:
# mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
# ls /dev/mypartition
base sizedevice type
# cat /dev/mypartition/size
On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
Peter Braam writes:
File system journal recovery can corrupt a snapshot, because it
copies data that needs to be preserved in a snapshot. During
journal replay such data may be copied again, but the source can
have new data already.
On Saturday 19 May 2001 13:37, Eric W. Biederman wrote:
For creating partitions you might want to do:
cat 1024 2048 /dev/sda/newpartition
How about:
# mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
# ls /dev/mypartition
base sizedevice type
# cat
On Wednesday 27 June 2001 23:22, Linus Torvalds wrote:
we could _easily_ have the setup
struct ext2_inode {
struct inode inode; /* Generic fields */
specific-ext2 struct; /* specific fields */
};
and then when ext2 calls down to the generic
On Thursday 28 June 2001 07:39, Alexander Viro wrote:
BTW, cost of extra dereferncing is trivial - when we access ext2-specific
part of inode we usually
a) do it more than once in a given function
b) access a lot of stuff outside of struct inode.
It's not the only cost:
- The
On Thursday 28 June 2001 03:48, Alexander Viro wrote:
On Thu, 28 Jun 2001, Daniel Phillips wrote:
Advantages: no extra memory use, no indirection, no memory allocation
overhead.
An advantage you overlooked: clean up fs.h so it doesn't have to include
every filesystem in the known
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
Daniel Phillips wrote:
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface
On Thursday 01 September 2005 10:49, Alan Cox wrote:
On Iau, 2005-09-01 at 03:59 -0700, Andrew Morton wrote:
- Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
possibly gain (or vice versa)
- Relative merits of the two offerings
You missed the important one -
On Thursday 01 September 2005 06:46, David Teigland wrote:
I'd like to get a list of specific things remaining for merging.
Where are the benchmarks and stability analysis? How many hours does it
survive cerberos running on all nodes simultaneously? Where are the
testimonials from users?
Struct iattr is not involved any more in such things as NOATIME inode flags.
There are no in-tree users of ia_attr_flags.
Signed-off-by Daniel Phillips [EMAIL PROTECTED]
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/hostfs/hostfs.h
2.6.13-rc5-mm1/fs/hostfs/hostfs.h
--- 2.6.13-rc5-mm1.clean/fs
On Friday 02 September 2005 17:17, Andi Kleen wrote:
The only thing that should be probably resolved is a common API
for at least the clustered lock manager. Having multiple
incompatible user space APIs for that would be sad.
The only current users of dlms are cluster filesystems. There are
On Friday 02 September 2005 20:16, Mark Fasheh wrote:
As far as userspace dlm apis go, dlmfs already abstracts away a large part
of the dlm interaction...
Dumb question, why can't you use sysfs for this instead of rolling your own?
Side note: you seem to have deleted all the 2.6.12-rc4
On Saturday 03 September 2005 06:35, David Teigland wrote:
Just a new version, not a big difference. The ondisk format changed a
little making it incompatible with the previous versions. We'd been
holding out on the format change for a long time and thought now would be
a sensible time to
On Saturday 03 September 2005 02:46, Wim Coekaerts wrote:
On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote:
On Friday 02 September 2005 20:16, Mark Fasheh wrote:
As far as userspace dlm apis go, dlmfs already abstracts away a large
part of the dlm interaction...
Dumb
On Saturday 03 September 2005 23:06, Joel Becker wrote:
dlmfs is *tiny*. The VFS interface is less than his claimed 500
lines of savings.
It is 640 lines.
The few VFS callbacks do nothing but call DLM
functions. You'd have to replace this VFS glue with sysfs glue, and
probably save very
On Sunday 04 September 2005 00:30, Joel Becker wrote:
You asked why dlmfs can't go into sysfs, and I responded.
And you got me! In the heat of the moment I overlooked the fact that you and
Greg haven't agreed to the merge yet ;-)
Clearly, I ought to have asked why dlmfs can't be done by
On Sunday 04 September 2005 01:00, Joel Becker wrote:
On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
Clearly, I ought to have asked why dlmfs can't be done by configfs. It
is the same paradigm: drive the kernel logic from user-initiated vfs
methods. You already have
On Sunday 04 September 2005 00:46, Andrew Morton wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
The model you came up with for dlmfs is beyond cute, it's downright
clever.
Actually I think it's rather sick. Taking O_NONBLOCK and making it a
lock-manager trylock because they're kinda
On Sunday 04 September 2005 03:28, Andrew Morton wrote:
If there is already a richer interface into all this code (such as a
syscall one) and it's feasible to migrate the open() tricksies to that API
in the future if it all comes unstuck then OK. That's why I asked (thus
far unsuccessfully):
On Monday 05 September 2005 05:19, Andrew Morton wrote:
David Teigland [EMAIL PROTECTED] wrote:
On Mon, Sep 05, 2005 at 01:54:08AM -0700, Andrew Morton wrote:
David Teigland [EMAIL PROTECTED] wrote:
We export our full dlm API through read/write/poll on a misc device.
inotify did
On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
On 2005-09-03T01:57:31, Daniel Phillips [EMAIL PROTECTED] wrote:
The only current users of dlms are cluster filesystems. There are zero
users of the userspace dlm api.
That is incorrect...
Application users Lars, sorry if I did
On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
On Monday 05 September 2005 10:49, Daniel Phillips wrote:
On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
On 2005-09-03T01:57:31, Daniel Phillips [EMAIL PROTECTED] wrote:
The only current users of dlms are cluster
On Monday 05 September 2005 22:03, Dmitry Torokhov wrote:
On Monday 05 September 2005 19:57, Daniel Phillips wrote:
On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
On Monday 05 September 2005 10:49, Daniel Phillips wrote:
On Monday 05 September 2005 10:14, Lars Marowsky-Bree
On Tuesday 06 September 2005 00:07, Dmitry Torokhov wrote:
On Monday 05 September 2005 23:02, Daniel Phillips wrote:
By the way, you said alpha server not alpha servers, was that just a
slip? Because if you don't have a cluster then why are you using a dlm?
No, it is not a slip
On Tuesday 06 September 2005 02:55, Dmitry Torokhov wrote:
On Tuesday 06 September 2005 01:48, Daniel Phillips wrote:
On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
do you think it is a bit premature to dismiss something even without
ever seeing the code?
You told me you
On Tuesday 10 July 2007 14:03, Chris Mason wrote:
This patch aims to demonstrate one way to replace buffer heads with a
few extent trees...
Hi Chris,
Quite terse commentary on algorithms and data structures, but I suppose
that is not a problem because Jon has a whole week to reverse engineer
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
Hi.
I'm pleased to announce first release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a node to
form tree-like storages.
On Friday 03 August 2007 06:49, Evgeniy Polyakov wrote:
...rx has global reserve (always allocated on
startup or sometime way before reclaim/oom)where data is originally
received (including skb, shared info and whatever is needed, page is
just an exmaple), then it is copied into per-socket
On Friday 03 August 2007 03:26, Evgeniy Polyakov wrote:
On Thu, Aug 02, 2007 at 02:08:24PM -0700, I wrote:
I see bits that worry me, e.g.:
+ req = mempool_alloc(st-w-req_pool, GFP_NOIO);
which seems to be callable in response to a local request, just the
case where NBD
On Saturday 04 August 2007 09:44, Evgeniy Polyakov wrote:
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
* storage can be formed on top of remote nodes and be
exported simultaneously (iSCSI is peer-to-peer only, NBD requires
device mapper and is synchronous)
In fact, NBD
On Sunday 05 August 2007 08:08, Evgeniy Polyakov wrote:
If we are sleeping in memory pool, then we already do not have memory
to complete previous requests, so we are in trouble.
Not at all. Any requests in flight are guaranteed to get the resources
they need to complete. This is guaranteed
On Sunday 05 August 2007 08:01, Evgeniy Polyakov wrote:
On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips wrote:
DST original code worked as device mapper plugin too, but its two
additional allocations (io and clone) per block request ended up
for me as a show stopper.
Ah
On Tuesday 07 August 2007 05:05, Jens Axboe wrote:
On Sun, Aug 05 2007, Daniel Phillips wrote:
A simple way to solve the stable accounting field issue is to add a
new pointer to struct bio that is owned by the top level submitter
(normally generic_make_request but not always
Hi Evgeniy,
Sorry for not getting back to you right away, I was on the road with
limited email access. Incidentally, the reason my mails to you keep
bouncing is, your MTA is picky about my mailer's IP reversing to a real
hostname. I will take care of that pretty soon, but for now my direct
On Tuesday 07 August 2007 13:55, Jens Axboe wrote:
I don't like structure bloat, but I do like nice design. Overloading
is a necessary evil sometimes, though. Even today, there isn't enough
room to hold bi_rw and bi_flags in the same variable on 32-bit archs,
so that concern can be scratched.
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe
([EMAIL PROTECTED]) wrote:
So, what did we decide? To bloat bio a bit (add a queue pointer) or
to use physical device limits? The latter requires to replace all
occurence of
(previous incomplete message sent accidentally)
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote:
So, what did we decide? To bloat bio a bit (add a queue pointer) or
to use physical device limits? The latter requires to
On Sunday 12 August 2007 22:36, I wrote:
Note! There are two more issues I forgot to mention earlier.
Oops, and there is also:
3) The bio throttle, which is supposed to prevent deadlock, can itself
deadlock. Let me see if I can remember how it goes.
* generic_make_request puts a bio in
On Monday 13 August 2007 02:13, Jens Axboe wrote:
On Mon, Aug 13 2007, Daniel Phillips wrote:
On Monday 13 August 2007 00:45, Jens Axboe wrote:
On Mon, Aug 13 2007, Jens Axboe wrote:
You did not comment on the one about putting the bio
destructor in the -endio handler, which looks
On Monday 13 August 2007 02:18, Evgeniy Polyakov wrote:
On Mon, Aug 13, 2007 at 02:08:57AM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
But that idea fails as well, since reference counts and IO
completion are two completely seperate entities. So unless end IO
just happens
On Monday 13 August 2007 03:06, Jens Axboe wrote:
On Mon, Aug 13 2007, Daniel Phillips wrote:
Of course not. Nothing I said stops endio from being called in the
usual way as well. For this to work, endio just needs to know that
one call means end and the other means destroy
On Monday 13 August 2007 01:23, Evgeniy Polyakov wrote:
On Sun, Aug 12, 2007 at 10:36:23PM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
(previous incomplete message sent accidentally)
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM
On Monday 13 August 2007 05:04, Evgeniy Polyakov wrote:
On Mon, Aug 13, 2007 at 04:04:26AM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote:
Oops, and there is also:
3) The bio throttle, which is supposed to prevent deadlock
On Monday 13 August 2007 05:18, Evgeniy Polyakov wrote:
Say you have a device mapper device with some physical device
sitting underneath, the classic use case for this throttle code.
Say 8,000 threads each submit an IO in parallel. The device mapper
mapping function will be called 8,000
On Tuesday 14 August 2007 05:46, Evgeniy Polyakov wrote:
The throttling of the virtual device must begin in
generic_make_request and last to -endio. You release the throttle
of the virtual device at the point you remap the bio to an
underlying device, which you have convinced yourself is
Say Evgeniy, something I was curious about but forgot to ask you
earlier...
On Wednesday 08 August 2007 03:17, Evgeniy Polyakov wrote:
...All oerations are not atomic, since we do not care about precise
number of bios, but a fact, that we are close or close enough to the
limit.
... in
On Tuesday 28 August 2007 02:35, Evgeniy Polyakov wrote:
On Mon, Aug 27, 2007 at 02:57:37PM -0700, Daniel Phillips
([EMAIL PROTECTED]) wrote:
Say Evgeniy, something I was curious about but forgot to ask you
earlier...
On Wednesday 08 August 2007 03:17, Evgeniy Polyakov wrote:
...All
On Friday 31 August 2007 14:41, Alasdair G Kergon wrote:
On Thu, Aug 30, 2007 at 04:20:35PM -0700, Daniel Phillips wrote:
Resubmitting a bio or submitting a dependent bio from
inside a block driver does not need to be throttled because all
resources required to guarantee completion must
On 10/28/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
While you're at it, it's probably worth splitting this out into
a small helper function.
Why? Is the same pattern called from more than one place?
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
Hi Jens,
This looks really useful.
On Wednesday 09 January 2008 00:52, Jens Axboe wrote:
Disadvantages:
- The file block mappings must not change while loop is using the
file. This means that we have to ensure exclusive access to the file
and this is the bit that is currently missing in the
On Wednesday 09 January 2008 01:16, Andreas Dilger wrote:
While an _incremental_ fsck isn't so easy for existing filesystem
types, what is pretty easy to automate is making a read-only snapshot
of a filesystem via LVM/DM and then running e2fsck against that. The
kernel and filesystem have
On Jan 15, 2008 6:07 PM, Pavel Machek [EMAIL PROTECTED] wrote:
I had write cache enabled on my main computer. Oops. I guess that
means we do need better documentation.
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on
On Jan 15, 2008 7:15 PM, Alan Cox [EMAIL PROTECTED] wrote:
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice
Hi Pavel,
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL
On Jan 17, 2008 1:25 PM, Chris mason [EMAIL PROTECTED] wrote:
So, I've put v0.11 out there. It fixes those two problems and will also
compile on older (2.6.18) enterprise kernels.
v0.11 does not have any disk format changes.
Hi Chris,
First, massive congratulations for bringing this to
1 - 100 of 108 matches
Mail list logo
