Alan Cox wrote:
I would be interested to know what the disk vendors intend to use as
their strategy when (with ATA) they have a 512 byte write from an older
file system/setup into a 4K block. The case where errors magically appear
Well, you have logical and physical sector size changes.
First
Alan Cox wrote:
First generation of 1K sector drives will continue to use the same
512-byte ATA sector size you are familiar with. A single 512-byte write
will cause the drive to perform a read-modify-write cycle. This
configuration is physical 1K sector, logical 512b sector.
The problem ca
Jan Engelhardt wrote:
On Mar 11 2007 18:51, Ric Wheeler wrote:
During the recent IO/FS workshop, we spoke briefly about the
coming change to a 4k sector size for disks on linux. If I
recall correctly, the general feeling was that the impact was
not significant since we already do most file syste
Jan Engelhardt wrote:
On Mar 11 2007 22:45, Ric Wheeler wrote:
Jan Engelhardt wrote:
On Mar 11 2007 18:51, Ric Wheeler wrote:
During the recent IO/FS workshop, we spoke briefly about the
coming change to a 4k sector size for disks on linux. If I
recall correctly, the general feeling was that
Christoph Hellwig wrote:
the occasional 2k sector SCSI MO device aswell. It would be nice to
get samples of large sector size ATA devices into the hands of developers
to do real world testing of the whole stack.
"hands of developers" meaning you specifically? :)
I've had a 512b-logical/1K-ph
Douglas Gilbert wrote:
Bryan Henderson wrote:
What is an odd-aligned disk?
s/disk/partition/ ?
Example: An odd-aligned disk in the 512-b logical / 1K-physical
scenario is where odd LBAs indicate the start of a 1K physical sector.
An even-aligned disk is where even LBAs indicate the start
David H. Lynch Jr wrote:
I do care about getting Reiser4 into the kernel so that it can
actually get a real test,
and frankly do not see any compelling reason that should not happen.
If the compelling reason is that it needs a test, I'd say its not ready.
Jeff
-
To unsubscri
David H. Lynch Jr wrote:
Jeff Garzik wrote:
If the compelling reason is that it needs a test, I'd say its not ready.
Can you please elaborate ? I am not sure I understand what you are
arguing ?
Despite his substantially less than polite rhetoric, I have read
Hans's post f
[EMAIL PROTECTED] wrote:
REISER4 FOR INCLUSION IN THE LINUX KERNEL.
Dave Lynch takes a reasoned approach to REISER4.
Dave Lynch wrote:
Jeff Garzik wrote:
If the compelling reason is that it needs a test, I'd say its not ready.
Can you please elaborate ? I am not sure I understand wha
David H. Lynch Jr wrote:
Jeff Garzik wrote:
David H. Lynch Jr wrote:
I'm arguing against circular logic: the claim that one cannot
determine reiser4's true usefulness unless its in the tree.
The better method is to get a distro to add reiser4, _then_ if it
proves worthy add it to
[EMAIL PROTECTED] wrote:
YOU GUYS WILL LAUGH ABOUT THIS:
Yes, we are laughing at you.
You keep using bonnie++ after being told it's a poor benchmark.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More m
Andreas Dilger wrote:
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based implementation and an ext3 implementation.
Actually, this is a
Andreas Dilger wrote:
My comment was just that the extent doesn't have to be explicitly zero
filled on the disk, by virtue of the fact that the uninitialized flag
will cause reads to return zero.
Agreed, thanks for the clarification.
Jeff
-
To unsubscribe from this list: send the li
Nick Piggin wrote:
- No deadlocks (hopefully). The buffer layer is technically deadlocky by
design, because it can require memory allocations at page writeout-time.
It also has one path that cannot tolerate memory allocation failures.
No such problems for fsblock, which keeps fsblock metada
Andrew Morton wrote:
b) We do what we normally don't do and reserve the syscall slots in mainline.
If everyone agrees it's going to happen... why not?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More ma
Theodore Tso wrote:
I don't think we have a problem here. What we have now is fine, and
It's fine for ext4, but not the wider world. This is a common problem
created by parallel development when code dependencies exist.
In any case, the plan is to push all of the core bits into Linus tre
Christoph Hellwig wrote:
On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote:
- In line with the above item, filesystem block allocation is performed
before a page is dirtied. In the buffer layer, mmap writes can dirty a
page with no backing blocks which is a problem if the filesystem
Christoph Hellwig wrote:
On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
The package build system is now based on autotools. The build system
supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
SUID_LDFLAGS). For more details see the README file
And this is real
Gerd Hoffmann wrote:
Jeff Garzik wrote:
Christoph Hellwig wrote:
And this is really dumb. autotools is a completely pain in the ass and
not useful at all for linux-only tools.
A myth. It is quite useful for packagers, because of the high Just
Works(tm) factor. After porting an entire
H. Peter Anvin wrote:
Miklos Szeredi wrote:
The *at() thing basically gives you the advantages of a CWD without
the disadvantages.
For example it could be useful to implement the functionality of
find(1) as a library interface.
What the *at() interfaces really do is fix/paper over a longstan
H. Peter Anvin wrote:
Jeff Garzik wrote:
What the *at() interfaces really do is fix/paper over a longstanding
wart in Unix: the cwd really should have been a standard file descriptor
(like stdin/stdout/stderr) instead of a magic piece of state maintained
in kernel space.
It's more than a
It seems jbd_debug() might need modification:
fs/ext4/inode.c: In function ‘ext4_write_inode’:
fs/ext4/inode.c:2906: warning: comparison is always true due to limited
range of data type
fs/jbd2/recovery.c: In function ‘jbd2_journal_recover’:
fs/jbd2/recovery.c:254: warning: comparison is alway
Alex Tomas wrote:
Good day,
please review ...
thanks, Alex
basic delayed allocation in VFS:
* block_prepare_write() can be passed special ->get_block() which
doesn't allocate blocks, but reserve them and mark bh delayed
* a filesystem can use mpage_da_writepages() with other ->get_block
Alex Tomas wrote:
Jeff Garzik wrote:
Is this based on Christoph's work?
Christoph, or some other XFS hacker, already did generic delalloc,
modeled on the XFS delalloc code.
nope, this one is simple (something I'd prefer for ext4).
The XFS one is proven and the work was already
Alex Tomas wrote:
So without the ability to attach specific I/O completions to bios
or support for unwritten extents directly in __mpage_writepage,
there is no way XFS can use this "generic" delayed allocation code.
I didn't say "generic", see Subject: :)
Well, it shouldn't even be in the VFS
Please add 'slab' to the title, otherwise you conflict with a feature of
the same name...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov wrote:
Hi.
I'm pleased to announce fourth 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.
This release includes new configuratio
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
I've been waiting for years for a smart person to come along and write a
POSIX-only distributed filesystem.
What exactly do you mean by "POSIX-only"?
Don't bother supporting attribu
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
I've been waiting for years for a smart person to come along and write a
POSIX-only distributed filesystem.
What exact
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 06:32:11PM -0400, Jeff Garzik wrote:
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
NFSv4.1 adds to the fun, by throwing interoperability completely out the
window.
What parts are you worried about in
Robin Humble wrote:
On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
It is my hope that you will put your skills towards a distributed
filesystem :) Of the current solutions, GFS (currently in kernel)
scales poorly, and NFS v4.1 is amazingly bloated and overly complex.
I've
Linus Torvalds wrote:
On Tue, 4 Dec 2007, Andi Drebes wrote:
Perhaps I'm missing somehting, but I think for cramfs, unfortunately,
there has to be this statement. The bitfields in the cramfs_inode structure
cause some problems.
I agree that bitfields can be painful, but they should likely be
t. ::writepage becomes
very simple then, but ::readpage becomes more complex.
Comments welcome... I think something -simple- like this can be used
to create tmpfs. I looked at the "shmfs" code, and it was huge compared
to this...
Jeff, the VM newbie
--
Jeff Garzik
--
Jeff Garzik | "When I do this, my computer freezes."
Building 1024 | -user
MandrakeSoft| "Don't do that."
| -level 1
/*
* Resizable simple ram filesystem for Linux.
* Hacked into tmpfs by Jeff Ga
is also another patch on lkml for ramfs, one which adds resource
limits. Ug, it can be done so much better with mount options.
Anyway... I'm straying off topic.
--
Jeff Garzik | "When I do this, my computer freezes."
Building 1024 | -us
maybe after a year of testing, if people
actually care, backport those features to ext2.
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message
w and shrink
* giving filesystems the ability to grow and shrink
On-line optimization (defrag, etc) shouldn't be hard once you have the
ability to move blocks and files around, which would come with the
ability to grow and shrink blkdevs and fs's.
--
Jeff Garzik | "Do you h
metadata miscdevs are a clean solution to what procfs hacks and ioctls
are trying to accomplish.
Jeff
--
Jeff Garzik | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft | step-daughter, b
cation]. At that point, userspace can safely run dump or tar or
whatever on the virtual snapshot device.
--
Jeff Garzik | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft | step-daughter, but other than
Jeff Garzik wrote:
> Notice also a "metadata miscdev" solves the problem of passing options
> on open -- just pass those options to the miscdev before you open it...
to be more clear, "it" == the data device, not the metadata miscdev
--
Jeff Garzik | &qu
tion/feature-removal-schedule.txt
@@ -270,3 +270,10 @@ Why: The new layer 3 independant connection tracking
replaces the old
Who: Patrick McHardy <[EMAIL PROTECTED]>
---
+
+What: JFFS (version 1) filesystem
+When: 2.6.21
+Why: No users or developers
+Who: Jeff Garzik <[EMAIL PROTECTED]>
+
+---
Josh Boyer wrote:
On 12/12/06, Jeff Garzik <[EMAIL PROTECTED]> wrote:
I have created the 'kill-jffs' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that
removes fs/jffs.
I argue that you can count the users (who aren't on 2.4) on one hand,
Jeff Garzik wrote:
When it's more likely to get struck by lightning than encounter
filesystem X on a random hard drive in the field, filesystem X need not
be in the kernel.
As people are already poking me:) I course meant "flash device" not
"hard drive".
SATA main
Bill Nottingham wrote:
Jeff Garzik ([EMAIL PROTECTED]) said:
It's always been the case that we remove Linux kernel code when the
number of users (and more importantly, developers) drops to near-nil.
So, drivers/net/3c501.c?
Depends on how motivated Alan remains ;-) Historically, i
Evgeniy Polyakov wrote:
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentiall
Evgeniy Polyakov wrote:
On Wed, Jan 10, 2007 at 06:11:26AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote:
Once the rate of change slows, Andrew should IMO definitely pick this up.
There are _tons_ of ideas to implement with kevent - so if we want, rate
will not slow down. As you can see, from
garzik/misc-2.6.git kill-jffs-prep
to receive the following updates:
Documentation/feature-removal-schedule.txt |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
Jeff Garzik (1):
Note that JFFS (v1) is to be deleted, in feature-removal-schedule.txt
diff --git a/Docume
ffs_proc.h
delete mode 100644 include/linux/jffs.h
Jeff Garzik (1):
Delete JFFS (version 1), as scheduled.
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index 0ba6af0..fc53239 100644
--- a/Documentation/feature-removal-schedule
.h
delete mode 100644 fs/jffs/jffs_fm.c
delete mode 100644 fs/jffs/jffs_fm.h
delete mode 100644 fs/jffs/jffs_proc.c
delete mode 100644 fs/jffs/jffs_proc.h
delete mode 100644 include/linux/jffs.h
Jeff Garzik (1):
Remove JFFS (version 1), as scheduled.
diff --git a/Documentation/featu
Theodore Tso wrote:
Can someone with knowledge of current disk drive behavior confirm that
for all drives that support bad block sparing, if an attempt to write
to a particular spot on disk results in an error due to bad media at
that spot, the disk drive will automatically rewrite the sector to
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
David Miller wrote:
From: Chris Mason <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 09:08:59 -0500
I've had requests to move the super down to 64k to make room for
bootloaders, which may not matter for sparc, but I don't really plan
on different locations for different arches.
The Sun disk label
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can for
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support barriers.
It seems far easier to make syn
Jamie Lokier wrote:
Jeff Garzik wrote:
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesy
55 matches
Mail list logo
