Takashi Sato wrote:
> o Elevate XFS ioctl numbers (XFS_IOC_FREEZE and XFS_IOC_THAW) to the VFS
> As Andreas Dilger and Christoph Hellwig advised me, I have elevated
> them to include/linux/fs.h as below.
> #define FIFREEZE_IOWR('X', 119, int)
> #define FITHAW _IOWR('X',
Takashi Sato wrote:
> Hi,
>
> Christoph Hellwig wrote:
>> On Fri, Feb 08, 2008 at 08:26:57AM -0500, Andreas Dilger wrote:
>>> You may as well make the common ioctl the same as the XFS version,
>>> both by number and parameters, so that applications which already
>>> understand the XFS ioctl will w
Theodore Tso wrote:
> The other approach would be to say, "oh well, the freeze ioctl is
> inherently dangerous, and root is allowed to himself in the foot, so
> who cares". :-)
I tend to agree. Either you need your fs frozen, or not, and if you do,
be prepared for the consequences.
> But it was
Alan Cox 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 to know which brands fail here, if any,
Mingming Cao wrote:
> [PATCH] jbd2 stats through procfs
>
> The patch below updates the jbd stats patch to 2.6.20/jbd2.
> The initial patch was posted by Alex Tomas in December 2005
> (http://marc.info/?l=linux-ext4&m=113538565128617&w=2).
> It provides statistics via procfs such as transaction li
this, but thought I'd send it out for comment.
(BTW another option would be to convert old-format files when accessed, but
that has its own set of tradeoffs...)
Thanks,
-Eric
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
---
Index: linux-2
Bodo Eggert wrote:
>> Ok, do you like this slightly better? It states the subsystem, the
>> function with the error, the block nr. in the case of a too-large block,
>> and the block device on which the error occurred.
>
> - how long is BDEVNAME_SIZE? Will it fit on the stack?
#define BDEVNAME_
d_entry,
etc, because on EIO they just move on to try the next page. This is
under the BKL, printk-storming as well. This can lock up the machine
for a very long time. Simply ratelimiting the printks gets things back
under control. Make the mes
Bodo Eggert wrote:
> Warning: I'm only looking at the patch.
>
> You are supposed to print an error message for a user, not to write in a
> chat window to a 1337 script kiddie. OK, you just matched the current style,
> and your patch is IMHO OK for a quick security fix, but:
>
> - Security fixes
ratelimiting the printks gets things back
under control.
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.6.22-rc4/fs/minix/itree_v1.c
===
--- linux-2.6.22-rc4.orig/fs/minix/itree_v1.c
+++ linux-2.6.22-rc4/fs
B for
V1, but 2GB for V2; this could still result in a lot of EIO reads in the V2
case, should the retry loops in minix_readdir & friends be short-circuited
somehow instead? A simple "break" rather than "continue" on error would
certainly resolve it, too...)
Signed
Jan Kara wrote:
> On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
>> Christoph Hellwig wrote:
>>> fallocate with the whence argument and flags is already quite complicated,
>>> I'd rather have another call for placement decisions, that would
>>> be called on an fd to do placement decissions for any
Ulrich Drepper wrote:
> Christoph Hellwig wrote:
>> fallocate with the whence argument and flags is already quite complicated,
>> I'd rather have another call for placement decisions, that would
>> be called on an fd to do placement decissions for any further allocations
>> (prealloc, write, etc)
>
Jörn Engel wrote:
> Does the allocation have to be persistent beyond lifetime of the file
> descriptor? It would be fairly simple to support the write guarantee
> while the file is open (or rather the inode remains cached) and drop it
> afterwards.
"The posix_fallocate() function shall ensure tha
Jan Kara wrote:
>> I am wondering if it is useful to add another mode to advise block
>> allocation policy? Something like indicating which physical block/block
>> group to allocate from (goal), and whether ask for strict contigous
>> blocks. This will help preallocation or reservation to choos
Badari Pulavarty wrote:
BTW, what is the interface for finding out what is the size of the
pre-allocated file ?
With XFS at least, "du," "stat," etc tell you a little:
[EMAIL PROTECTED] test]# touch resvsp
[EMAIL PROTECTED] test]# xfs_io resvsp
xfs_io> resvsp 0 10g
The file is 0 length, but
Badari Pulavarty wrote:
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, w
Amit K. Arora wrote:
Might want more error checking in there, something like (rough cut)...
(or is some of this glibc's job?)
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct file *file;
+ struct inode *inode;
+ long ret;
> +
> + ret = -EINVAL;
>
Nathan Scott wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkag
Andrew Morton wrote:
On Tue, 16 Jan 2007 21:05:20 +0900
[EMAIL PROTECTED] wrote:
...
+ext4_ext_replace_branches(struct inode *org_inode, struct inode *dest_inode,
+ pgoff_t from_page, pgoff_t dest_from_page,
+ pgoff_t count_page, unsigned long *delete_start)
+{
+
Christoph Hellwig wrote:
>
>> return -ENOMEM;
>> +/* set to high value to try and avoid collisions with loop below */
>> +inode->i_ino = 0x;
>> +insert_inode_hash(inode);
>
> This is odd. Can't we just add some constant base to the loop below?
>
I thought the sa
Jeff Layton wrote:
> Resending this set of patches to the list per Al Viro's request. I've gotten
> no comments so far, so I'll presume that denotes consent and just ask Andrew
> to merge them if I don't hear anything after this ;-).
>
> --[snip]-
>
> Since Joern mentioned that he thought
Eric Sandeen wrote:
> Take 2... all in one file. I suppose I really did know better than
> to create that new header. ;-)
>
> Better?
Ugh, sorry for the internal/external cross-post, that was supposed to be
to LKML... not enough sleep last night. Please adjust replies
accordingly
etter to create an EIO-returner for each
actual op signature. Since so few ops share a signature, I just went ahead
& created an EIO function for each individual file & inode op that returns
a value.
Thanks,
-Eric
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.
Stephen Rothwell wrote:
> Hi Eric,
>
> On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
>> So here's the first stab at fixing it. I'm sure there are style points
>> to be hashed out. Putting all the functions as static inlines in a
oblem, I'm all ears.
Thanks,
-Eric
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc3/fs/bad_inode.h
===
--- /dev/null
+++ linux-2.6.20-rc3/fs/bad_inode.h
@@ -0,0 +1,266 @@
+/* fs/bad_inode.h
+ * ba
Eric Sandeen wrote:
We saw problems w/ xfs doing AIO+DIO into a sparse file.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217098
It seemed that xfs was doing "extent conversion" at the wrong offsets, so
written regions came up as unwritten (zeros) and stale data was expo
ems to fix it up.
Comments?
Thanks,
-Eric
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.6.18/fs/direct-io.c
===
--- linux-2.6.18.orig/fs/direct-io.c
+++ linux-2.6.18/fs/direct-io.c
@@ -
loop will never make any
>> progress.
>
> Actually, I think Eric Sandeen was working on similar fixes already, and
> instead of doing a per-item check each time we look at the entry it does
> a full-block check the first time it is read (as ext2 does).
>
>>
30 matches
Mail list logo
