| Takashi Sato | Re: [RFC] ext3 freeze feature
I don't think a mmap()'ed file is written to a block device while a filesystem
is frozen. pdflush starts the writing procedure of the mmap()'ed file's
data and calls ext3_ordered_writepage. ext3_ordered_writepage calls
ext3_journal_start to get the journal handle. As a result, the process
waits for unfreeze in start_this_handle.
ext3_ordered_writepage
ext3_journal_start
ext3_journal_start_sb
journal_start
start_this_handle <--- wait here
I actually tried freezing the filesystem after upd...
| Feb 13, 4:23 am 2008 |
| Christoph Hellwig |
| Feb 13, 3:05 am 2008 |
| Christoph Hellwig | Re: i_version changes
i_version. Instead of hardcoding i_version updates in file_update_time
it would be better to add an ia_verstion to struct iattr and update it
Probably through export_operations somehow. Andreas mentioned in the
other reply that he wants it only conditionally due to the overhead
on extN, and enabling this from an export operation called when nfs
exporting a filesystem.
Btw, stupid question: the commit message for the i_version changes
mentions this is to work around lack of granularity for ct...
| Feb 13, 8:52 am 2008 |
| J. Bruce Fields | Re: i_version changes
It's not OK to update it only sometimes. If updates are made while nfsd
isn't running, those needed to be reflected in the change attribute, so
the changes aren't missed when nfsd comes back up.
So I'm inclined to think this should be an option that's permanently
associated with the filesystem, rather than something that's changed on
or off by nfsd (or even on or off with each mount).
--b.
-
| Feb 13, 4:26 pm 2008 |
| NeilBrown | Re: i_version changes
For NFSD's needs, it is only necessary that changes in i_version that are
potentially visible over NFS actually be stored on disk.
You could come up with an interface where NFSD sets a flag when it reads
i_version, and changes to the file only change i_version if the flag is
set (at which point the flag is cleared).
This would give fully correct NFS semantics, and no overhead when NFS access
is not in use
This flag would need to be stored in stable storage too, so probably easiest
to make it...
| Feb 13, 5:19 pm 2008 |
| J. Bruce Fields | Re: i_version changes
Sure. I'd rather have a per-superblock "use i_version" bit than a
per-inode "use i_version" bit, just for simplicity's sake, unless
there's a really convincing case that it helps.
--b.
-
| Feb 13, 5:36 pm 2008 |
| Peter Staubach | Re: i_version changes
I don't think that this is quite true. If the file is changed
when the NFS server is not running, then the value of i_version
which is used when the NFS server starts up again must be
different than the value which was previously used when the NFS
server was previously running.
Is the perceived performance hit really going to be as large
as suspected? We already update the time fields fairly often
and we don't pay a huge penalty for those, or at least not a
penalty that we aren't willing to pa...
| Feb 13, 5:32 pm 2008 |
| NeilBrown | Re: i_version changes
As I said, the "NFS has seen this i_version" flag needs to be on
stable storage, e.g. the lsb of the i_version. This will ensure that
any change after NFSD saw the i_version will cause the i_version to
be updated.
So I think it can provide correct semantics.
Precise details:
NFSD: when reading i_version
take lock
tmp = i_version
i_version |= 1
drop lock
return tmp & ~1;
VFS when making any change:
take lock
if (i_version & 1) {
...
| Feb 13, 6:06 pm 2008 |
| Trond Myklebust | Re: i_version changes
Support for 64-bit on-disk time stamps alone does not suffice. In order
to label all file/directory changes unambiguously, you would also need
nanosecond timekeeping support.
An example is XFS, which has had on-disk support for 64-bit time stamps
since forever, but is in practice limited by the Linux default 250Hz
internal clock. We've seen plenty of examples of NFS clients missing
updates on the resulting filesystem due to the fact that they occurred
within 1/250 sec of each other.
Cheers
...
| Feb 13, 10:07 am 2008 |
| Andreas Dilger | Re: i_version changes
The other issue which unfortunately makes ctime a non-starter is the
ability of ctime to go backward due to clock changes.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-
| Feb 13, 11:12 am 2008 |
| Andreas Dilger | Re: i_version changes
One of the reasons NOT to make it mandatory is that it forces updates
of the inode after every write. On ext3/ext4 this is expensive, as the
ext3_dirty_inode() packs the inode from memory into the buffer each time,
so that it can be journaled.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-
| Feb 13, 5:25 am 2008 |
| KOSAKI Motohiro | Re: [PATCH 4/8][for -mm] mem_notify v6: memory_pressure_noti...
Hmmm
actually, This portion become code broat through some bug reports.
Yes, I think it again and implement it more simplefy.
nice point out.
to be honest, I don't think at mem-cgroup until now.
OK.
I'll implement it again more simplefy.
OK.
Agghh..
I will don't use gmail at next post.
sorry.
and,
I hope merge only poll_wait_exclusive() and wake_up_locked_nr()
if you don't mind.
this 2 portion anybody noclaim about 2 month.
and I think it is useful function by many people....
| Feb 13, 2:37 am 2008 |
| Andi Kleen |
| Feb 13, 11:03 am 2008 |
| Theodore Tso | Re: BTRFS partition usage...
The reason why we don't put the superblock at 0 is not because it
screws over the sparc, but because on many systems (including x86) the
bootsector is stored at 0. It's not hard for mke2fs to zap the boot
sector which we do on all architectures *except* sparc, to avoid
nuking the disk label. (Chris just missed the "#ifndef __sparc //
#define ZAP_BOOTBLOCK // #endif" at the beginning of mke2fs.c)
This is the best of all words; it makes sparc happy; it allows boot
loaders to put the x86 standard ...
| Feb 12, 8:45 pm 2008 |
| Bryan Henderson | Re: BTRFS partition usage...
I don't believe a cylinder of wasted disk space is significant. I don't
believe a cylinder of disk is worth adding the complexity of sharing a
partition to a filesystem. That complexity translates into engineering
time and mistakes.
Your other arguments for making a hole in the filesystem, based on
tradition, are more convincing.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
| Feb 12, 9:25 pm 2008 |
| David Miller | Re: BTRFS partition usage...
From: Jan Engelhardt <jengelh@computergmbh.de>
That's really not an option when you only have 16-bits in the disk
label for some of these values, which is the case for Sun disk
labels and some others (f.e. BSD).
Jan, please get past this, it's a real issue and we therefore have to
skip the initial 1K or so in order to provide something even
approaching sane.
No modern filesystem should put it's superblock at position zero.
-
| Feb 12, 9:08 pm 2008 |
| Jeff Garzik |
| Feb 12, 10:10 pm 2008 |
| Christoph Hellwig | Re: BTRFS partition usage...
I'd rather say what Sun did with their disklabels was rather unfortunate :)
But yeah, new filesystem should cater for it's braindamage because it
doesn't have any kind of runtime cost at all. XFS was designed for
IRIX back then which had disklabels just like the SUN ones, just without
the braindamage of having the disklabel inside the partition..
-
| Feb 13, 3:02 am 2008 |
| Rene Herman | Re: BTRFS partition usage...
I haven't followed this thread, but in case it matters -- this sounds fairly
confused.
Not sure what you're saying, but the MSDOS partition table has its root
table in the very first sector on the disk, at offset 0x1be = 0x200 - 4 *
sizeof(struct partition) - 2 (that is, 4 entries at the end of that first
sector, followed by a 2-byte signature).
That 0x7e00 that you are speaking of sounds somewhat like the _memory_
address the BIOS loads that first sector to: 0x7c00. It then jumps there to...
| Feb 12, 9:22 pm 2008 |
| David Miller | Re: BTRFS partition usage...
From: Jan Engelhardt <jengelh@computergmbh.de>
You can go update every sparc machine's firmware then, you
can't boot off of a device that doesn't use a sun disk
label.
Your expectations are unrealistic, and it's just simpler to
do something sane and follow the majority of existing practice
by putting the superblock a few blocks into the partition.
-
| Feb 12, 9:09 pm 2008 |
